Skip site navigation (1) Skip section navigation (2)

Re: Using multi-row technique with COPY

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using multi-row technique with COPY
Date: 2005-11-28 12:32:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Nov 28, 2005 at 09:39:36AM +0000, Simon Riggs wrote:
> On Mon, 2005-11-28 at 09:40 +0100, Martijn van Oosterhout wrote:
> > Whatever happened to that idea to build as entire datafile with COPY or
> > some external tool and simply copy it into place and update the
> > catalog?
> What's wrong with tuning the server to do this? 

It was just a question. I remember it being mentioned but didn't hear
if it had been rejected or just not implemented.

I was wondering if maybe we can approach this another way. Whenever you
create a new block by fetching with P_NEW you pretty much know that no
other backends are going to be interested in this block. Doesn't this
mean you can simply hold this block exclusively until the end of the
transaction? Hence you can avoid all the locking on this block.

If this is acheives the same reduction in block locking then it would
be active in far more places such as SELECT INTO or any large copy (I
think index creation is already special cased). Once a block has been
written once it would revert to standard locking.

Is this feasable?

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

pgsql-hackers by date

Next:From: Mario WeilguniDate: 2005-11-28 13:00:32
Subject: Getting different number of results when using hashjoin on/off
Previous:From: Hannu KrosingDate: 2005-11-28 12:05:08
Subject: Re: Using multi-row technique with COPY

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group