Re: Idea for getting rid of VACUUM FREEZE on cold pages

From: Joe Conway <mail(at)joeconway(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Josh Berkus <josh(at)agliodbs(dot)com>, Jesper Krogh <jesper(at)krogh(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date: 2010-05-27 20:21:55
Message-ID: 4BFED463.7090109@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/27/2010 12:39 PM, Robert Haas wrote:
> On Thu, May 27, 2010 at 3:15 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Jesper Krogh <jesper(at)krogh(dot)cc> wrote:
>>
>>> Couldn't pages that are totally filled by the same transaction, be
>>
>>> frozen on the initial write?
>>
>> As far as I'm aware, that can only be done if:
>>
>> (a) The tuples were written within the same transaction which
>> created or truncated the table.
>>
>> *or*
>>
>> (b) The writing transaction and all transactions concurrent to it
>> have completed by the time the page is about to be written.
>
> Actually, I think this is true only in case (b). In case (a), you
> mess up visibility with respect to other command-IDs within the
> transaction.
>

(a) can work if it is all in one command, CREATE TABLE AS SELECT...

Additionally we were discussing COPY in the FROM clause, which means you
could CREATE TABLE AS SELECT ... FROM (COPY ...). That would allow bulk
loading with hint bits already set (and tuples frozen?).

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2010-05-27 20:25:00 Re: [RFC] Security label support
Previous Message Robert Haas 2010-05-27 20:11:18 Re: [RFC] Security label support