RE: [INTERFACES] Slow join query optimisation?
От | Ansley, Michael |
---|---|
Тема | RE: [INTERFACES] Slow join query optimisation? |
Дата | |
Msg-id | 1BF7C7482189D211B03F00805F8527F748C312@S-NATH-EXCH2 обсуждение исходный текст |
Список | pgsql-interfaces |
I've mentioned this before in a previous discussion some months back, but surely allowing stored procs to return result sets would alleviate this problem. Then, the back end could use the stored proc mechanism to cache those queries it felt were used often enough by simply creating a stored proc for them (which is a brainless operation), alternatively, the developer could optimise the application by writing certain stored procs into the application. Most commercial dbs allow this, and I'm surprised that more people don't see this as a significant feature. I'm not exactly sure how they do this, whether it's through the return of a cursor, or whether it's a special data type that stores the rows: whatever, we can't be that far from being able to hack something like this together. MikeA -----Original Message----- From: Tom Lane To: dougt@mugc.cc.monash.edu.au Cc: pgsql-interfaces@postgreSQL.org Sent: 99/12/02 05:21 Subject: Re: [INTERFACES] Slow join query optimisation? Douglas Thomson <dougt@mugc.cc.monash.edu.au> writes: > Is there any way to turn off the optimisation? Or perhaps some way to > work out the optimal strategy once, and then provide this information > directly? Not at the moment. There's been some talk of caching query plans, which would get the job done, but none of the current developers are working on that now. It'll probably happen someday... regards, tom lane ************ ************ ************
В списке pgsql-interfaces по дате отправления: