Re: modifying the tbale function

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Islam Hegazy <islheg(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: modifying the tbale function
Date: 2007-03-19 11:00:21
Message-ID: 45FE6D45.7050407@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
>> Returning control to the backend for every row returned would likely be
>> excessive, but you could return once every k rows and get most of the
>> benefits of both approaches (k might be on the order of 1000).
>
> However, this still leaves us with no idea how to persuade perl, tcl,
> python, et al to cooperate.

It seem like a useful optimization for C-functions, though. I was caught
by surprise a while ago when I realized that the way I've been using to
create simple test data quickly:

INSERT INTO foo SELECT key FROM generate_series(1, <large number>) key

materializes the generate_series result set first.

I'd like to have that changed, even if we leave the behavior as it is
for PLs.

Another affected use case is using dblink to copy large tables.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-03-19 11:21:43 Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)
Previous Message Heikki Linnakangas 2007-03-19 10:51:57 Re: CREATE INDEX and HOT (was Question: pg_class attributes and race conditions ?)