Noah Misch <n...@leadboat.com> writes:
> On Mon, Dec 19, 2011 at 12:05:09PM -0500, Robert Haas wrote:
>> Yet another option, which I wonder whether we're dismissing too
>> lightly, is to just call GetSnapshotData() and do the scan using a
>> plain old MVCC snapshot. Sure, it's more expensive than SnapshotNow,
>> but is it expensive enough to worry about?
That might actually be workable ...
> 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.
Poking around a bit, it looks to me like one of the bigger users of
non-cache-fronted SnapshotNow scans is dependency.c. So maybe testing
the speed of large cascaded drops would be a more relevant test case.
For instance, create a schema containing a few thousand functions, and
see how long it takes to drop the schema.
Another thing that would be useful to know is what effect such a change
would have on the time to run the regression tests with
CLOBBER_CACHE_ALWAYS. That has nothing to do with any real-world
performance concerns, but it would be good to see if we're going to
cause a problem for the long-suffering buildfarm member that does that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
