Postgres 8.3 HOT and non-persistent xids

From: "Mike C" <smith(dot)not(dot)western(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Postgres 8.3 HOT and non-persistent xids
Date: 2007-12-19 22:14:33
Message-ID: bd0eabd0712191414o64aa5193w5fe57dff622c178c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

Can someone clarify HOT updates for me (and perhaps put more detail
into the docs?). Is this statement correct: the HOT technique is used
on *any* table so long as no indexed column is affected.

create table T (A int, B int);
create index TB on T (B);
insert into T (A,B) Values (1,2);

So if I do an update that is identical to the existing row, nothing changes?

update T set A=1, B=2 where A=1;

If I change the non-indexed field, A, then HOT applies and no new tuple needed?

update T set A=2, B=2 where A=1;

If I change the indexed field, B, then HOT doesn't apply and a new
tuple is needed?

update T set A=2,B=3 where A=2;

Is that correct?

Actually, what actually happens when you get an update with redundant
information, e.g.

update T set A=2,B=4 where A=2;

The value of A hasn't changed, does postgres still write the value?

And for non-persistent transaction ids, the documentation says that
this is for read-only transactions. What defines a read-only
transaction for this purpose? Does postgres check to see if a SELECT
includes e.g. a sequence change via nextval? If I mark the transaction
as readonly using the PG JDBC driver, will that be sufficient?

Thank you,

Mike

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marcin 2007-12-19 22:27:47
Previous Message GMail 2007-12-19 21:41:36 Re: INDEX on a composite type