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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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-28 07:48:36
Message-ID: 4BFF7554.8050609@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27/05/10 22:56, Robert Haas wrote:
> On Thu, May 27, 2010 at 3:52 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>> On Thu, May 27, 2010 at 3:15 PM, Kevin Grittner
>>
>>>> (a) The tuples were written within the same transaction which
>>>> created or truncated the table.
>>
>>> In case (a), you mess up visibility with respect to other
>>> command-IDs within the transaction.
>>
>> Surely that problem is surmountable?
>
> I proposed an idea at PGCon, but I believe Tom and Heikki thought it
> was far too grotty to consider.

No, I think it's surmountable too. We discussed hacks to teach the MVCC
checks that all frozen tuples on a table that was created in the same
transaction (i.e. the same cases where we skip WAL logging) were
actually created by the running transaction, and check commandid
accordingly.

Or detect simple DML commands where we know that the command doesn't
read the table. COPY would usually fall into that category, though
non-immutable input functions make that a bit iffy.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2010-05-28 08:28:27 Re: tsvector pg_stats seems quite a bit off.
Previous Message Heikki Linnakangas 2010-05-28 07:08:26 Re: Patch submission deadline for CommitFest 2010-07