Re: HOT patch, missing things - Mailing list pgsql-hackers

From Tom Lane
Subject Re: HOT patch, missing things
Date
Msg-id 16294.1186675017@sss.pgh.pa.us
Whole thread Raw
In response to Re: HOT patch, missing things  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Responses Re: HOT patch, missing things  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> I started with this. ISTM to support partial indexes, we must check
> the old and new tuple against partiality match.
> ...
> For functional index, we should apply the function to the old and new
> tuple and compare the outcome. If the results are same, HOT update
> is feasible.

I don't like either of these.  They are going to be extremely expensive
if the function or predicate is expensive (because you're going to be
doing two evaluations that you might get no benefit from).  Also, if the
function is not as immutable as it's supposed to be, you will soon have
an utterly corrupt index, with entries pointing at rows they in fact
don't match and never did.  We have so far managed to avoid any really
strong dependencies on the requirement of index-function immutability
--- your queries may not work very well if the function isn't immutable,
but you are not at risk of system-level data corruption.  With this, you
will be.  Since we are entirely dependent on users to mark immutable
functions correctly (and have not always gotten it right ourselves :-(),
I don't think this is an acceptable risk.

If we can't do better than that (and offhand I don't see how to), then
I agree with the current approach of disabling HOT when functional or
partial indexes are present.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Compilation of pg 7.4.17 fails on HP-UX
Next
From: "Merlin Moncure"
Date:
Subject: Re: crypting prosrc in pg_proc