From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Matthew <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Benchmark Data requested |
Date: | 2008-02-05 16:09:36 |
Message-ID: | 47A88A40.5090502@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Matthew wrote:
> On Tue, 5 Feb 2008, Richard Huxton wrote:
>>> Why would you need to lock the table?
>>
>> Because you're not really writing the WAL, which means you can't let
>> anyone else get their data into any of the blocks you are writing
>> into. You'd basically want to write the disk blocks then "attach" them
>> in some way.
>
> So what's wrong with "reserving" the space using the WAL, then everyone
> else will know. After all, when you write the data to the WAL, you must
> have an idea of where it is meant to end up. My suggestion is that you
> go through all the motions of writing the data to the WAL, just without
> the data bit.
Well, now you're looking at page-level locking for the data blocks, or
at least something very similar. Not sure what you'd do with indexes
though - don't see a simple way of avoiding a large lock on a btree index.
If you reserved the space in advance that could work. But you don't know
how much to reserve until you've copied it in.
You could of course have a set of co-operating processes all
bulk-loading while maintaining a table-lock outside of the those. It
feels like things are getting complicated then though.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Jignesh K. Shah | 2008-02-05 16:14:39 | Re: Benchmark Data requested |
Previous Message | Richard Huxton | 2008-02-05 15:59:23 | Re: Benchmark Data requested |