On Tue, 2012-06-12 at 22:06 -0400, Robert Haas wrote:
> > How much of a savings did we get from PD_ALL_VISIBLE when it was added
> > into the page-at-a-time visibility check?
> >
> > >From 608195a3a3656145a7eec7a47d903bc684011d73:
> >
> > "In addition to the visibility map, there's a new PD_ALL_VIS
On Tue, Jun 12, 2012 at 6:26 PM, Jeff Davis wrote:
> On Tue, 2012-06-12 at 18:02 -0400, Tom Lane wrote:
>> Or (d) it's not a problem, since the inserting XID is still busy
>> according to the readers' snapshots.
>
> How much of a savings did we get from PD_ALL_VISIBLE when it was added
> into the
On Tue, Jun 12, 2012 at 6:02 PM, Tom Lane wrote:
> The part I think is actually hard is how to clean up if the inserting
> xact doesn't reach commit. I think what we're basically looking at here
> is pushing more cost into that path in order to avoid cost in successful
> cases. The first design
On Tue, 2012-06-12 at 18:02 -0400, Tom Lane wrote:
> Or (d) it's not a problem, since the inserting XID is still busy
> according to the readers' snapshots.
How much of a savings did we get from PD_ALL_VISIBLE when it was added
into the page-at-a-time visibility check?
>From 608195a3a3656145a7eec
On Tue, 2012-06-12 at 17:53 -0400, Bruce Momjian wrote:
> Well, truncating tables that were empty on the load would certainly be
> a easy to do --- not sure if that helps us, though.
This goes back to the single-loader-into-an-empty-table case, which I'd
like to get away from. I think we already h
Jeff Davis writes:
> In those terms, we can reframe the questions as: what do we do about
> reads during the load?
> Answers could include:
> (a) nothing -- reads during a load are potentially dirty
> (b) readers ignore hint bits during the load, and pay the penalty
> (c) allow only INSERT/
On Tue, 2012-06-12 at 13:10 -0400, Robert Haas wrote:
> I don't think it's going to solve the problem in general, but TBH I
> don't think Jeff's proposal is, either. I mean, ignoring
> xmin-committed, xmax-committed, and all-visible bits is going to come
> with a pretty steep performance penalty a
On Tue, Jun 12, 2012 at 01:31:05PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > I don't think it's going to solve the problem in general, but TBH I
> > don't think Jeff's proposal is, either. I mean, ignoring
> > xmin-committed, xmax-committed, and all-visible bits is going to come
> > with a
On Tue, 2012-06-12 at 13:31 -0400, Tom Lane wrote:
> Yeah; the notion of adding cycles to the visibility-check code paths,
> which would add cost even for users who have no use at all for this
> feature, is close to being a deal-breaker for me. I would rather see
> us designing this around the ide
On Tue, 2012-06-12 at 08:42 -0400, Robert Haas wrote:
> Instead of trying to maintain MVCC semantics, maybe we should just
> have something like COPY (FROZEN) that just writes frozen tuples into
> the table and throws MVCC out the window. Seems like that would be a
> lot easier to implement and sa
On Wed, Jun 6, 2012 at 8:42 PM, Jeff Davis wrote:
> On Wed, 2012-06-06 at 15:08 -0400, Robert Haas wrote:
>> On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis wrote:
>> > Thoughts?
>>
>> Simon already proposed a way of doing this that doesn't require
>> explicit user action, which seems preferable to a
Robert Haas writes:
> I don't think it's going to solve the problem in general, but TBH I
> don't think Jeff's proposal is, either. I mean, ignoring
> xmin-committed, xmax-committed, and all-visible bits is going to come
> with a pretty steep performance penalty all of its own. I don't doubt
> t
On Tue, Jun 12, 2012 at 12:41 PM, Merlin Moncure wrote:
>>> -1: The situation with hint bit i/o patterns on many workloads is
>>> untenable but it's not safe to assume MVCC can be ditched in those
>>> workloads. Also, COPY does nothing about deletes. Neither does the
>>> proposal as stated but I
On Tue, Jun 12, 2012 at 5:41 PM, Merlin Moncure wrote:
> Also it's not safe to assume that insertion heavy clients
> can be migrated to COPY. For example, JDBC bulk loading AFAIK does
> not use COPY and even if it did wouldn't be able to decorate the
> command for a long time for most production
On Tue, Jun 12, 2012 at 11:12 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas wrote:
>>> Instead of trying to maintain MVCC semantics, maybe we should just
>>> have something like COPY (FROZEN) that just writes frozen tuples into
>>> the table and thr
Tom Lane wrote:
> I think Robert's idea has a fair amount of merit: mainly because
> it will probably satisfy 90% of use cases for 1% of the work.
+1, especially if we include a pg_dump option to write the COPY
statements with that option.
-Kevin
--
Sent via pgsql-hackers mailing list (pgs
Merlin Moncure writes:
> On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas wrote:
>> Instead of trying to maintain MVCC semantics, maybe we should just
>> have something like COPY (FROZEN) that just writes frozen tuples into
>> the table and throws MVCC out the window. Seems like that would be a
>> l
On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas wrote:
> On Mon, Jun 11, 2012 at 2:16 AM, Jeff Davis wrote:
>> On Wed, 2012-06-06 at 22:16 -0400, Noah Misch wrote:
>>> Note that, currently, only VACUUM sets PD_ALL_VISIBLE and visibility map
>>> bits.
>>> Would you make something else like heap_mult
On Mon, Jun 11, 2012 at 2:16 AM, Jeff Davis wrote:
> On Wed, 2012-06-06 at 22:16 -0400, Noah Misch wrote:
>> Note that, currently, only VACUUM sets PD_ALL_VISIBLE and visibility map
>> bits.
>> Would you make something else like heap_multi_insert() be able to do so?
>
> That was the plan (roughly
On Wed, 2012-06-06 at 22:16 -0400, Noah Misch wrote:
> Note that, currently, only VACUUM sets PD_ALL_VISIBLE and visibility map bits.
> Would you make something else like heap_multi_insert() be able to do so?
That was the plan (roughly). I was thinking about doing it at the time a
new page was all
On Mon, Jun 04, 2012 at 06:26:04PM -0700, Jeff Davis wrote:
> I propose a special user-initiated loading mode at the table
> granularity. During this time, readers must ignore PD_ALL_VISIBLE,
> HEAP_XMIN_COMMITTED, and the visibility map entirely. However, writers
> may set all of those bits before
On Wed, 2012-06-06 at 15:08 -0400, Robert Haas wrote:
> On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis 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 tho
On Wed, Jun 06, 2012 at 03:08:05PM -0400, Robert Haas wrote:
> On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis 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, e
On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis 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
Introduction:
=
A lot of progress has been made on the checksums issue, with Simon's
excellent work beginning to gain consensus:
http://archives.postgresql.org/message-id/CA
+u5nmkw_gbs6qq_y8-rjgl1v7mvw2hwbhartb8lojhnpfx...@mail.gmail.com
For the purposes of this p
25 matches
Mail list logo
