Re: ALTER TABLE lock strength reduction patch is unsafe
От | Noah Misch |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | 20111220162302.GA5979@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
|
Список | 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 по дате отправления: