X-Original-To: pgsql-patches-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id B66299FB2B9 for ; Tue, 18 Jul 2006 13:25:48 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 48374-01-2 for ; Tue, 18 Jul 2006 13:25:39 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from joeconway.com (wsip-68-15-9-201.sd.sd.cox.net [68.15.9.201]) by postgresql.org (Postfix) with ESMTP id B3E219FB437 for ; Tue, 18 Jul 2006 12:05:58 -0300 (ADT) Received: from [206.190.70.130] (account jconway HELO [172.16.1.115]) by joeconway.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 4053858; Tue, 18 Jul 2006 08:05:57 -0700 Message-ID: <44BCF8D5.5080109@joeconway.com> Date: Tue, 18 Jul 2006 08:05:57 -0700 From: Joe Conway User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Dunstan CC: Christopher Kings-Lynne , Bernd Helmle , Peter Eisentraut , "Patches (PostgreSQL)" , Susanne Ebrecht Subject: Re: [HACKERS] 8.2 features? References: <44B69778.5050104@dunslane.net> <50461.84.63.113.55.1152832991.squirrel@pezone.net> <44B7ADFC.90205@dunslane.net> <44BC0432.3040509@joeconway.com> <44BC661F.80609@joeconway.com> <44BCD06C.3060409@calorieking.com> <44BCF1D4.3010807@dunslane.net> In-Reply-To: <44BCF1D4.3010807@dunslane.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/136 X-Sequence-Number: 20290 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