Re: AW: AW: [HACKERS] Another nasty cache problem
От | Hannu Krosing |
---|---|
Тема | Re: AW: AW: [HACKERS] Another nasty cache problem |
Дата | |
Msg-id | 38A484C1.7EE47CDD@tm.ee обсуждение исходный текст |
Ответ на | AW: AW: [HACKERS] Another nasty cache problem (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
Zeugswetter Andreas SB wrote: > > > Is'nt the "blank portal" the name of the cursor you get when you just > > do a select without creating a cursor ? > > Yes, is that still so ? >From my toy implementation of fe-be protocol in python for v.6.2 I remember it to be, i.e. the cursors name is blank if declare cursor ;fetch all ... is implicit > > > I don't really see any advantage, that psql does not do a fetch loop > > > with a portal. > > > > It only increases traffic, as explicit fetch commands need to be sent > > to backend. If one does not declare a cursor, an implicit > > fetch all from > > blank is performed. > > I don't really see how a fetch every x rows (e.g.1000) would add significant > overhead. But it would start a transaction and possibly lock the table as well. > The first fetch could still be done implicit, it would only fetch 1000 > instead of fetch all. maybe we should add a macro language to psql and thus make it into something else, like pgsh ;) > Thus there would only be overhead for large result sets, where the > wasted memory is of real concern. The whole fe-be protocol should be re-thought at some stage (or an additional protocol + client libs added) anyway, as current one is quite weak at XOPEN CLI support both ODBC and JDBC drivers are full of hacks to be compatible with standard usages. Also performance suffers on inserts adn selects as prepared queries can't be currently used from client programs (they can from SPI). ------------------- Hannu
В списке pgsql-hackers по дате отправления: