Re: final patch - plpgsql: for-in-array
От | Robert Haas |
---|---|
Тема | Re: final patch - plpgsql: for-in-array |
Дата | |
Msg-id | AANLkTinxpS7nYRL9Uv47-FMrjMff0KJA1Dt_FsfHWnCv@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: final patch - plpgsql: for-in-array (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: final patch - plpgsql: for-in-array
|
Список | pgsql-hackers |
On Wed, Nov 24, 2010 at 1:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Cédric Villemain <cedric.villemain.debian@gmail.com> writes: >> I think you (Robert) misunderstood dramatically what Pavel try to do. >> Pavel did an excellent optimization work for a specific point. This >> specific point looks crucial for me in the current behavior of >> PostgreSQL[1]. AFAIS Pavel didn't want to implement a genious syntax, >> but an optimization feature. > > As near as I can tell, Pavel is bullheadedly insisting on adding new > syntax, not on the optimization aspect of it. I already pointed out > how he could get 100% of the performance benefit using the existing > syntax, but he doesn't appear to be willing to pursue that route. Right, that was my impression, too. But, I think this may be partly a case of people talking past each other. My impression of this conversation was a repetition of this sequence: A: This syntax is bad. B: But it's way faster! ...which makes no sense. However, what I now think is going on here is that there are really two separate things that are wished for here - a more compact syntax, and a performance improvement. And taken separately, I agree with both of those desires. PL/pgsql is an incredibly clunky language syntactically, and it's also slow. A patch that improves either one of those things has value, whether or not it also does the other one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: