X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 14F989FA4E3 for ; Wed, 19 Jul 2006 18:41:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 75477-05 for ; Wed, 19 Jul 2006 21:41:52 +0000 (UTC) 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 097A49FA4AE for ; Wed, 19 Jul 2006 18:41:51 -0300 (ADT) Received: by joeconway.com (CommuniGate Pro PIPE 4.1.8) with PIPE id 4056429; Wed, 19 Jul 2006 14:41:51 -0700 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 4056427; Wed, 19 Jul 2006 14:41:37 -0700 Message-ID: <44BEA710.6060700@joeconway.com> Date: Wed, 19 Jul 2006 14:41:36 -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: Joe Conway CC: Tom Lane , Christopher Kings-Lynne , "Hackers (PostgreSQL)" , Andrew Dunstan , Bernd Helmle , Peter Eisentraut , Susanne Ebrecht Subject: Re: [PATCHES] 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> <5842.1153246741@sss.pgh.pa.us> <44BD8854.9060506@calorieking.com> <15212.1153279954@sss.pgh.pa.us> <44BDB2F5.7080003@joeconway.com> In-Reply-To: <44BDB2F5.7080003@joeconway.com> 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/838 X-Sequence-Number: 86693 Joe Conway wrote: > Tom Lane wrote: > >> Christopher Kings-Lynne writes: >> >>> Strange. Last time I checked I thought MySQL dump used 'multivalue >>> lists in inserts' for dumps, for the same reason that we use COPY >> >> I think Andrew identified the critical point upthread: they don't try >> to put an unlimited number of rows into one INSERT, only a megabyte >> or so's worth. Typical klugy-but-effective mysql design approach ... > > OK, so given that we don't need to be able to do 1 million > multi-targetlist insert statements, here is rev 2 of the patch. I did some testing today against mysql and found that it will easily absorb insert statements with 1 million targetlists provided you set max_allowed_packet high enough for the server. It peaked out at about 600MB, compared to my test similar last night where it was using about 3.8 GB when I killed it. So the question is, do we care? If we do, I'll start looking for a new rev 3 strategy (ideas/pointers etc very welcome). If not, I'll start working on docs and regression test. Thanks, Joe