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
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 |