Re: Trying to understand page structures in PG

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: rob stone <floriparob(at)gmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Rakesh Kumar *EXTERN*" <rakeshkumar464a3(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Trying to understand page structures in PG
Date: 2016-04-07 01:31:46
Message-ID: CAMkU=1zrwRiSd9JutrjBecxxUewsE_D-CjNbpW28fNTOg0PbcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 6, 2016 at 8:35 AM, rob stone <floriparob(at)gmail(dot)com> wrote:
> On Wed, 2016-04-06 at 10:33 +0000, Albe Laurenz wrote:
>
> <snip>
>> Every row has two system columns associated with it: xmin and xmax
>>
>> xmin is the transaction ID that created the row, while xmax is
>> the transaction ID that removed the row.
>>
>> So when an update takes place, xmax of the original row and xmin
>> of the new row are set to the transaction ID of the current
>> transaction.

> Out of curiosity:-
> 1) If you only updated a column defined as BOOLEAN, DATE or TIMESTAMP,
> the tuples physical size should be the same. Is it written back to the
> same page with altered xmin, xmax values?

Being the same size doesn't matter, because it *has* to be copied.

If there is room for the copy to go onto the same page, then that is
done. If there is not room, then it goes onto a different page.

>
> 2) If you defined a table with a FILLFACTOR of say 70%, and there is
> still space left on its page for the updated tuple, does the same
> apply?
>
> I am curious because of "while xmax is the transaction ID that
> *removed* the row".

"marked for removal" would be more accurate. If the row were actually
physically removed, it would no longer have a xmax to set.

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2016-04-07 04:39:12 Re: what database schema version management system to use?
Previous Message Jeff Janes 2016-04-07 01:17:10 Re: database is not accepting commands to avoid wraparound data loss in database