Re: [PERFORM] Big IN() clauses etc : feature proposal
От | PFC |
---|---|
Тема | Re: [PERFORM] Big IN() clauses etc : feature proposal |
Дата | |
Msg-id | op.s9coppqfcigqcu@apollo13 обсуждение исходный текст |
Ответ на | Re: [PERFORM] Big IN() clauses etc : feature proposal ("Jim C. Nasby" <jnasby@pervasive.com>) |
Список | pgsql-hackers |
> On Tue, May 09, 2006 at 06:29:31PM +0200, PFC wrote: >> You mean the cursors'storage is in fact the same internal machinery >> as a temporary table ? > > Use the source, Luke... LOL, yeah, I should have, sorry. > See tuplestore_begin_heap in backend/utils/sort/tuplestore.c and > heap_create_with_catalog in backend/catalog/heap.c. You'll find that > creating a tuplestore is far easier than creating a temp table. I had used intuition (instead of the source) to come at the same conclusion regarding the level of complexity of these two... But I'll look at the source ;) > Perhaps it would be worth creating a class of temporary tables that used > a tuplestore, although that would greatly limit what could be done with > that temp table. Just selecting from it I guess, but that's all that's needed. Anymore would duplicate the functionality of a temp table. I find cursors awkward. The application can FETCH from them, but postgres itself can't do it in SQL, unless using FOR.. IN in plpgsql... It would be a powerful addition to be able to split queries, factor out common parts between multiple queries, etc, using this system, it can even be used to execute an inner part of a query, then plan the rest according to the results and execute it... without the overhead of a temp table.
В списке pgsql-hackers по дате отправления: