Re: CRCs

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

In response to

  • Re: CRCs at 2001-01-13 17:49:34 from Tom Lane

Browse pgsql-hackers by date

  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.