Search Postgresql Archives

Postgres 8.3 HOT and non-persistent xids

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux