Re: [HACKERS] Performance testing of COPY (SELECT) TO
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Performance testing of COPY (SELECT) TO |
Дата | |
Msg-id | 20060828163630.GN27526@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Performance testing of COPY (SELECT) TO (Zoltan Boszormenyi <zboszor@dunaweb.hu>) |
Ответы |
Re: [HACKERS] Performance testing of COPY (SELECT) TO
Re: [HACKERS] Performance testing of COPY (SELECT) TO |
Список | pgsql-patches |
Zoltan Boszormenyi wrote: > Alvaro Herrera írta: > >Remember that we were talking about supporting views, not tables. And > >if a view uses a slow query then you are in immediate danger of having a > >slow COPY. This may not be a problem but it needs to be discussed and > >an agreement must be reached before introducing such a change (and not > >during feature freeze). > > COPY relname TO meant tables _and_ views to me. > My previous tsting showed no difference between > COPY table TO and COPY (SELECT * FROM table) TO. > Similarly a slow query defined in the view should show > no difference between COPY view TO and > COPY (SELECT * FROM view) TO. The difference is that we are giving a very clear distinction between a table and a view. If we don't support the view in the direct COPY, but instead insist that it be passed via a SELECT query, then the user will be aware that it may be slow. "relname" at this point may mean anything -- are you supporting sequences and toast tables as well? > And remember, Bruce put the original COPY view TO > patch into the unapplied queue, without the SELECT > feature. All sort of junk enters that queue so that's not an argument. (Not meant to insult Bruce -- I'm just saying that he doesn't filter stuff. We've had patches rejected from the queue before plenty of times.) > Rewriting COPY view TO internally to > COPY (SELECT * FROM view) TO is very > straightforward, even if you think it's ugly. > BTW, why is it ugly if I call raw_parser() > from under src/backend/parser/*.c ? > It is on a query distinct to the query the parser > is currently running. Or is it the recursion > that bothers you? It's not a possible infinite > recursion. It's ugly because you are forcing the system to parse something that was already parsed. On the other hand I don't see why you are arguing in favor of a useless feature whose coding is dubious; you can have _the same thing_ with nice code and no discussion. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-patches по дате отправления: