Re: [HACKERS] What about LIMIT in SELECT ?
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] What about LIMIT in SELECT ? |
Дата | |
Msg-id | 36261DF7.D20368A0@trust.ee обсуждение исходный текст |
Ответы |
Re: [HACKERS] What about LIMIT in SELECT ?
Re: [HACKERS] What about LIMIT in SELECT ? |
Список | pgsql-hackers |
Jan Wieck wrote: > And I got the time to hack around about this. > <... a lovely explanation of a patch to achiev 60X speedup for a typical web query ...> > The speedup for the cursor/fetch scenario is so impressive > that I'll create a post 6.4 patch. I don't want it in 6.4 > because there is absolutely no query in the whole regression > test, where it suppresses the sort node. Good, then it works as expected ;) More seriously, it is not within powers of current regression test framework to test speed improvements (only the case where performance-wise bad implementation will actually crash the backend, as in the cnfify problem, but AFAIK we dont test for those now) > So we have absolutely no check that it doesn't break anything. If it did pass the regression, then IMHO it did not break anything. I would vote for putting it in (maybe with a 'set fix_optimiser_stupidity on' safeguard to enable it). I see no reason to postpone it to 6.4.1 and force almost everybody to first patch their copy and then upgrade very soon. I would even go far enough to call it a bugfix, as it does not really introduce any new functionality only fixes some existing functionality so that much bigger databases can be actually used. I would compare it in this sense to finding the places where username/password get truncated below their actual values in pg_passwd ;) --------------- Hannu Krosing
В списке pgsql-hackers по дате отправления: