On Sat, Oct 5, 2013 at 6:39 AM, Stephen Frost <sfr...@snowman.net> wrote:

> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Fri, Oct 4, 2013 at 11:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > > David Rowley <dgrowle...@gmail.com> writes:
> > >> Here's a small patch which greatly increases the speed of
> > >> pg_dump --column-inserts.
> > >
> > > The reason why no one's paid any attention to the speed of that code
> path
> > > is that if you care about dump/restore speed, you should be using the
> COPY
> > > code paths instead.  Is it really worth adding code and complexity to
> > > pg_dump for this?
> >
> > One possible reason to care about this is if you're trying to move
> > data to another database.  The INSERT format is more portable.
> >
> > Also, this isn't really adding any net code or complexity AFAICS.
>
> Agreed- this looks more like a "gee, that makes a lot of sense" than a
> "wow, that's way more complicated".  Not a whole lot of point in
> building up a known-to-be-constant string on every iteration of the
> loop.
>
>
These words made me think that the changes I made were not quite enough to
satisfy this what you said.
I understand that most people won't use the --column-inserts feature, but
that's not really a great reason to have not very clever and wasteful code
in there. This fruit was so low hanging it was pretty much touching the
ground, so I couldn't resist fixing it when I saw it.

The attached revised patch goes a little further and prepares everything
that is constant on processing the first row, this now includes the "INSERT
INTO tablename " part. I don't think the changes make the code any harder
to read, the code which builds the staticStmt fits into my small laptop
screen.

The timings with my benchmark look something like:

Unpatched: 9200 ms
Version 0.1:  5700 ms
Version 0.2: 5250 ms

So it does shave off a bit more, for what it's worth.

David




>         Thanks,
>
>                 Stephen
>

Attachment: pg_dump_colinsert_v0.2.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to