Re: COPY speedup

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pierre Frédéric Caillaud <lists(at)peufeu(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY speedup
Date: 2009-08-12 22:20:39
Message-ID: 20090812222039.GO5721@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pierre Frédéric Caillaud escribió:

> But when I see a big red button, I just press it to see what happens.
> Ugly hacks are useful to know how fast the thing can go ; then the
> interesting part is to reimplement it cleanly, trying to reach the
> same performance...

Right -- now that you've shown a 6x speedup increase, it is clear that
it makes sense to attempt a reimplementation. It also means it makes
sense to have an additional pair or two of input/output functions.

> >Maybe add new methods, fastrecv/fastsend etc. Types that don't
> >implement them would simply use the slow methods, maintaining
> >backwards compatibility.

> I considered doing it like this, but it is a lot more work : adding
> entries to the system catalogs, creating all the new functions,
> deciding what to do with getTypeBinaryOutputInfo (since there would
> be 2 variants), etc. Types that don't support the new functions
> would need some form of indirection to call the old functions
> instead, etc. In a word, doable, but kludgy, and I would need help
> from a system catalog expert.

Right.

> Also, on upgrade, information about the new functions must be inserted
> in the system catalogs ? (I don't know how this process works).

No, that's not how pg_migrator works. Catalog upgrades are handled by
pg_dump/pg_restore, so you don't need to worry about it at all.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-12 22:26:05 Re: surprising trigger/foreign key interaction
Previous Message Alvaro Herrera 2009-08-12 22:16:28 schemapg.h