Re: Bulk Insert tuning
От | Simon Riggs |
---|---|
Тема | Re: Bulk Insert tuning |
Дата | |
Msg-id | 1206021870.4285.550.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Bulk Insert tuning (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-patches |
On Tue, 2008-02-26 at 21:36 +0000, Simon Riggs wrote: > On Tue, 2008-02-26 at 15:12 -0500, Tom Lane wrote: > > Simon Riggs <simon@2ndquadrant.com> writes: > > > Following patch implements a simple mechanism to keep a buffer pinned > > > while we are bulk loading. > > > > This will fail to clean up nicely after a subtransaction abort, no? > > Yes, will fix. Additional line in AbortSubTransaction handles this. > > (For that matter I don't think it's right even for a top-level abort.) > > And I'm pretty sure it will trash your table entirely if someone > > inserts into another relation while a bulk insert is happening. > > (Not at all impossible, think of triggers for instance.) > > The pinned buffer is separate from the preferred block for each > relation; BulkInsertBuffer isn't used for determining the block to > insert into. If you try to insert into a block that differs from the > pinned one it unpins it and re-pins the new one. So it is always safe > with respect to the data in the table. > > It can run into recursive bulk insert ops but that just destroys the > performance advantage, its not actually dangerous. I'm about to start refactoring code as suggested, so wanted to drop off another version to allow everybody to examine the safety/not of this approach. (So this patch is WIP) -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
Вложения
В списке pgsql-patches по дате отправления: