Re: IN list processing performance (yet again)
| От | Dave Tenny |
|---|---|
| Тема | Re: IN list processing performance (yet again) |
| Дата | |
| Msg-id | 3ED514A2.8060107@attbi.com обсуждение исходный текст |
| Ответ на | Re: IN list processing performance (yet again) (Mario Weilguni <mweilguni@sime.com>) |
| Список | pgsql-performance |
Mario Weilguni wrote:
There are some places however where it doesn't work well in query logic, though I don't have an example off the top of my head
since I've worked around it in all my queries.
Yup, been there, done that, but thanks, it's a good tidbit for the postgresql unaware.I'm reminded to relay to the PostgreSQL devos that I might be able to do more in the join or subquery department if PostgreSQL had better performing MAX functions and a FIRST function for selecting rows from groups. ("Performing" being the operative word here, since the extensible architecture of PostgreSQL currently makes for poorly performing MAX capabilities and presumably similar user defined aggregate functions).MIN/MAX is almost in every case replaceable: select bar from fooorder by bar limit 1; instead of select max(bar) from foo;
There are some places however where it doesn't work well in query logic, though I don't have an example off the top of my head
since I've worked around it in all my queries.
В списке pgsql-performance по дате отправления: