Re: [HACKERS] Performance testing of COPY (SELECT) TO
От | Zoltan Boszormenyi |
---|---|
Тема | Re: [HACKERS] Performance testing of COPY (SELECT) TO |
Дата | |
Msg-id | 44F316D3.2080801@dunaweb.hu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Performance testing of COPY (SELECT) TO (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: [HACKERS] Performance testing of COPY (SELECT) TO
|
Список | pgsql-patches |
Alvaro Herrera írta: > Zoltan Boszormenyi wrote: > >> Andrew Dunstan írta: >> >>> Alvaro Herrera wrote: >>> >>>> Böszörményi Zoltán wrote: >>>> >>>> >>>>> what's the problem with COPY view TO, other than you don't like it? :-) >>>>> >>>> The problem is that it required a ugly piece of code. Not supporting it >>>> means we can keep the code nice. The previous discussion led to this >>>> conclusion anyway so I don't know why we are debating it again. >>>> >>> What is so ugly about it? I haven't looked at the code, but I am >>> curious to know. >>> > > It used a "SELECT * FROM %s" string that was passed back to the parser. > > >>> I also don't recall the consensus being quite so clear cut. I guess >>> there is a case for saying that if it's not allowed then you know that >>> "COPY relname TO" is going to be fast. But, code aesthetics aside, the >>> reasons for disallowing it seem a bit thin, to me. >>> >> I would say the timing difference between >> "COPY table TO" and "COPY (SELECT * FROM table) TO" >> was noise, so it's not even faster. >> > > 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. And remember, Bruce put the original COPY view TO patch into the unapplied queue, without the SELECT feature. 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. >> And an updatable VIEW *may* allow COPY view FROM... >> > > May I remind you that we've been in feature freeze for four weeks > already? Now it's *not* the time to be drooling over cool features that > would be nice to have Noted. However, as the COPY view TO is a straight internal rewrite, a COPY view FROM could also be. Even if it's a long term development. I wasn't proposing delaying beta. Best regards, Zoltán Böszörményi
В списке pgsql-patches по дате отправления: