ctid & updates - Mailing list pgsql-general

From Joshua b. Jore
Subject ctid & updates
Date
Msg-id Pine.BSO.4.44.0206031301140.11800-100000@kitten.greentechnologist.org
Whole thread Raw
Responses Re: ctid & updates  (Jan Wieck <janwieck@yahoo.com>)
Re: ctid & updates  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
1#
I saw a post from Jan Wieck about how ctid can be used for a fast update.
I noticed that ctid changes on update (as expected since it's really a new
row). Is there anyway to get the new ctid from the update so later
updates to the row can continue to use ctid to zero in on the row
location?

2#
Also, is ctid unique for each row? I would guess so since it looks like
(and I'm guessing) that ctid is a page/row offset. So there should be only
one thing at each ctid address. Is that correct that ctid is unique to a
table? Can anything interesting be done with the empty space? Is there any
way to find the maximum ctid and look for quantities of empty space? I
assume a user-side program could use that data to see how much unused,
yet allocated space there is in a table?

That might be the "You don't have to be a PostgreSQL hacker" version of
looking for compressible (via relocation) tables.

Joshua b. Jore ; http://www.greentechnologist.org ; 1121 1233 1311 200
1201 1302 1211 200 1201 1303 200 1300 1233 1313 1211 1302 1212 1311 1230
200 1201 1303 200 1321 1233 1311 1302 200 1211 1232 1211 1231 1321 200
1310 1220 1221 1232 1223 1303 200 1321 1233 1311 200 1201 1302 1211 232
200 1112 1233 1310 1211 200 1013 1302 1211 1211 1232 201 22


pgsql-general by date:

Previous
From: Jan Wieck
Date:
Subject: Re: performance issues with DBI module when data too big
Next
From: Andrew Perrin
Date:
Subject: Re: [ADMIN] performance issues with DBI module when data too big