Re: 9.3: load path to mitigate load penalty for checksums - Mailing list pgsql-hackers

From Robert Haas
Subject Re: 9.3: load path to mitigate load penalty for checksums
Date
Msg-id CA+TgmoaSVH8jWPgKB8zxcAvH=7v2wLG1AfKiHNBi1Ae5JHFc8A@mail.gmail.com
Whole thread Raw
In response to 9.3: load path to mitigate load penalty for checksums  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: 9.3: load path to mitigate load penalty for checksums
Re: 9.3: load path to mitigate load penalty for checksums
List pgsql-hackers
On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> Thoughts?

Simon already proposed a way of doing this that doesn't require
explicit user action, which seems preferable to a method that does
require explicit user action, even though it's a little harder to
implement.  His idea was to store the XID of the process creating the
table in the pg_class row, which I think is *probably* better than
your idea of having a process that waits and then flips the flag.
There are some finicky details though - see previous thread for
discussion of some of the issues.

It would be very nice to have a method that detects whether or not
there is only one open snapshot in a particular backend.  Any time
that condition is met, tuples written into a table created or
truncated in the current transaction can be written with
HEAP_XMIN_COMMITTED already set.  That is not as nice as being able to
set HEAP_XMIN_COMMITTED *and* PD_ALL_VISIBLE *and* the visibility map,
but it would still be a big improvement over the status quo.  I would
like to see us get that part done and committed and then worry about
writing the tuples with PD_ALL_VISIBLE set as a separate project.  In
many cases it would also be nice to write the tuples pre-frozen, so I
think we should look for a design that will support that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: "page is not marked all-visible" warning in regression tests
Next
From: Tom Lane
Date:
Subject: Avoiding adjacent checkpoint records