Re: Benchmark Data requested
От | Richard Huxton |
---|---|
Тема | Re: Benchmark Data requested |
Дата | |
Msg-id | 47A88A40.5090502@archonet.com обсуждение исходный текст |
Ответ на | Re: Benchmark Data requested (Matthew <matthew@flymine.org>) |
Ответы |
Re: Benchmark Data requested
|
Список | 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
В списке pgsql-performance по дате отправления: