Re: [HACKERS] Another nasty cache problem - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: [HACKERS] Another nasty cache problem
Date
Msg-id 389A581F.47C0D822@nimrod.itg.telecom.com.au
Whole thread Raw
In response to Another nasty cache problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Another nasty cache problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

> With the fix I just committed, current sources execute the above query
> in constant backend memory space.  psql's space usage still goes to the
> moon, of course, since it's trying to buffer the whole query result :-(
> ... but there's no way around that short of a major redesign of libpq's
> API.  When and if we switch over to CORBA, we really need to rethink
> the client access API so that buffering the query result in the client-
> side library is an option not a requirement.

What about portals? Doesn't psql use portals?


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] how to deal with sparse/to-be populated tables
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] how to deal with sparse/to-be populated tables