On Tue, 2008-02-26 at 15:12 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] 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?
(For that matter I don't think it's
On Tue, 2008-02-26 at 21:36 +, Simon Riggs wrote:
On Tue, 2008-02-26 at 15:12 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] 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
Gavin Sherry wrote:
On Tue, Feb 26, 2008 at 02:43:51PM +, Simon Riggs wrote:
Following patch implements a simple mechanism to keep a buffer pinned
while we are bulk loading.
CK Tan and I worked on something similar but the problem we discovered
was self locking. Consider a primary key: we
On Tue, Feb 26, 2008 at 02:43:51PM +, Simon Riggs wrote:
Following patch implements a simple mechanism to keep a buffer pinned
while we are bulk loading.
CK Tan and I worked on something similar but the problem we discovered
was self locking. Consider a primary key: we insert a tuple into
Added to TODO:
o Consider using a ring buffer for COPY FROM
http://archives.postgresql.org/pgsql-patches/2008-02/msg00140.php
---
Simon Riggs wrote:
On Tue, 2008-02-26 at 15:12 -0500, Tom Lane wrote:
On Tue, 2008-02-26 at 14:43 +, Simon Riggs wrote:
Following patch implements a simple mechanism to keep a buffer pinned
while we are bulk loading.
Performance gains measured as +20% gain for CREATE TABLE as SELECT, and
15-17% for COPY on very short rows. Measurable difference drops away
Simon Riggs [EMAIL PROTECTED] 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?
(For that matter I don't think it's right even for a top-level abort.)
And I'm pretty sure
