From: Joe Conway <mail@joeconway.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>
Cc: Bernd Helmle <mailings@oopsware.de>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Patches (PostgreSQL) <pgsql-patches@postgresql.org>
Cc: Susanne Ebrecht <susanne.ebrecht@credativ.de>
Subject: Re: [HACKERS] 8.2 features?
Date: Tue, 18 Jul 2006 08:05:57 -0700
Message-ID: <44BCF8D5.5080109@joeconway.com> (raw)
In-Reply-To: <44BCF1D4.3010807@dunslane.net>
References: <44B69778.5050104@dunslane.net>
<50461.84.63.113.55.1152832991.squirrel@pezone.net>
<ECCAAC0A3182895D3D12B0E8@[172.26.14.247]>
<44B7ADFC.90205@dunslane.net>
<44BC0432.3040509@joeconway.com>
<44BC661F.80609@joeconway.com>
<44BCD06C.3060409@calorieking.com>
<44BCF1D4.3010807@dunslane.net>
Andrew Dunstan wrote:
> Christopher Kings-Lynne wrote:
>
>>> The major downside is that somewhere between 9000 and 10000
>>> VALUES-targetlists produces "ERROR: stack depth limit exceeded".
>>> Perhaps for the typical use-case this is sufficient though.
>>>
>>> I'm open to better ideas, comments, objections...
>>
>> If the use case is people running MySQL dumps, then there will be
>> millions of values-targetlists in MySQL dumps.
>
> Yeah. The fabricated select hack does feel wrong to me. Taking a quick
> 2 minute look at the grammar it looks like a better bet would be to make
> InsertStmt.targetList a list of lists of values rather than just a list
> of values. Of course, that would make the changes more invasive. Even
> with that we'd still be reading the whole thing into memory ... is there
> a sane way to cache the inline data before statement execution?
I started down the path of making InsertStmt.targetList a list of
targetlists. The problem is finding a reasonable way to make that
available to the executor. Back to the drawing board I guess.
I have similar concerns with the millions of values-targetlists comment
that Chris made. But I don't see how we can cache the data easily short
of inventing a List alternative that spills to disk.
> I guess we can just say that for true bulk load our supported mechanism
> is still just COPY, but it would be a pity to restrict a feature that is
> in the standard that way.
True
Joe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: mail@joeconway.com, andrew@dunslane.net, chris.kings-lynne@calorieking.com, mailings@oopsware.de, peter_e@gmx.net, pgsql-patches@postgresql.org, susanne.ebrecht@credativ.de
Subject: Re: [HACKERS] 8.2 features?
In-Reply-To: <44BCF8D5.5080109@joeconway.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox