Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nMKKSSPwMJ1eTZYoyC80pHMGd_G0CjSb_vaSbQFta3o3nQ@mail.gmail.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
Re: ALTER TABLE lock strength reduction patch is unsafe |
Список | pgsql-hackers |
On Tue, Dec 20, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Noah Misch <noah@leadboat.com> writes: >> On Mon, Dec 19, 2011 at 11:13:57PM -0500, Tom Lane wrote: >>> ... 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. > > No, I'm not sure about that at all. In particular I think that > CatalogCacheFlushCatalog is pretty expensive and so the snapshot costs > could be a larger part of a more-realistic test. Attached patch makes SnapshotNow into an MVCC snapshot, initialised at the start of each scan iff SnapshotNow is passed as the scan's snapshot. It's fairly brief but seems to do the trick. Assuming that is the right approach, some timings 10,000 functions individually Create 15.7s 14.3s 14.8s 14.8s Drop 11.9s 11.7 11.6s 12.0s 10,000 functions in a schema Create ... same ... Drop Cascade 2.5s That seems OK to me. Any feedback? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: