From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Do we need so many hint bits? |
Date: | 2012-11-16 14:43:12 |
Message-ID: | CAHyXU0z7Wso4pFWS7L_6wnTn6YQ+zK867cZKiD3CU4E_Y-aHgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 15, 2012 at 9:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> It occurred to me recently that many of the hint bits aren't terribly
>> important (at least it's not obvious to me). HEAP_XMIN_COMMITTED clearly
>> has a purpose, and we'd expect it to be used many times following the
>> initial CLOG lookup.
>
> Right.
>
>> But the other tuple hint bits seem to be there just for symmetry,
>> because they shouldn't last long. If HEAP_XMIN_INVALID or
>> HEAP_XMAX_COMMITTED is set, then it's (hopefully) going to be vacuumed
>> soon, and gone completely. And if HEAP_XMAX_INVALID is set, then it
>> should just be changed to InvalidTransactionId.
>
> Hm. It is not cheaper to change xmax to 0 than it is to set the hint
> bit --- you still need a write, and there are also added locking and
> atomicity worries --- so I'm not convinced by your argument there.
> But you might be right that the expected number of wins from the other
> two bits is a lot less.
Is that true in a post checksum world though? Given that we are
logging changes can we relax atomicity expectations? IIRC xmin/xmax
are aligned, how come you can't just set InvalidTransactionId for
INVALID and 'FrozenTransactionId' for COMMITTED? Why can't you do
this now?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2012-11-16 14:50:33 | Re: [v9.3] writable foreign tables |
Previous Message | Hannu Krosing | 2012-11-16 14:27:07 | Re: another idea for changing global configuration settings from SQL |