From: | Horst Herb <hherb(at)malleenet(dot)net(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CRCs |
Date: | 2001-01-14 10:39:40 |
Message-ID: | 0101142139400G.01349@munin.midgard |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sunday 14 January 2001 04:49, Tom Lane wrote:
> A row-level CRC might be useful for this, but it would have to be on
> the data only (not the tuple commit-status bits). It'd be totally
> impractical with a block CRC, I think. To do it with a block CRC, every
> time you changed *anything* in a heap page, you'd have to find all the
> index items for each row on the page and update their copies of the
> heap block's CRC. That could easily turn one disk-write into hundreds,
> not to mention the index search costs. Similarly, a check value that is
> affected by tuple status updates would enormously increase the cost of
> marking tuples committed or dead.
Ah, finally. Looks like we are moving in circles (or spirals ;-) )Remember
that some 3-4 months ago I requested help from this list several times
regarding a trigger function that implements a crc only on the user defined
attributes? I wrote one in pgtcl which was slow and had trouble with the C
equivalent due to lack of documentation. I still believe this is that useful
that it should be an option in Postgresand not a user defined function.
Horst
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-01-14 13:01:01 | RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea |
Previous Message | Lamar Owen | 2001-01-14 06:32:52 | RPMS for 7.1beta3 in progress. |