Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

From Noah Misch
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id 20111220162302.GA5979@tornado.leadboat.com
Whole thread Raw
In response to Re: ALTER TABLE lock strength reduction patch is unsafe  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TABLE lock strength reduction patch is unsafe  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 19, 2011 at 11:13:57PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > I created a function that does this in a loop:
> 
> >         HeapTuple t;
> 
> >         CatalogCacheFlushCatalog(ProcedureRelationId);
> >         t = SearchSysCache1(PROCOID, ObjectIdGetDatum(42) /* int4in */);
> >         if (!HeapTupleIsValid(t))
> >             elog(ERROR, "cache lookup failed for function 42");
> >         ReleaseSysCache(t);
> 
> ... but this performance test seems to me to be entirely misguided,
> because it's testing a situation that isn't going to occur much in the
> field, precisely because the syscache should prevent constant reloads of
> the same syscache entry.

> [ideas for more-realistic tests]

Granted, but I don't hope to reliably measure a change in a macro-benchmark
after seeing a rickety 2% change in a micro-benchmark.


pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: [PATCH] Fix ScalarArrayOpExpr estimation for GIN indexes
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe