Re: Instability in TRUNCATE regression test
От | Jim C. Nasby |
---|---|
Тема | Re: Instability in TRUNCATE regression test |
Дата | |
Msg-id | 20060628171829.GG44573@pervasive.com обсуждение исходный текст |
Ответ на | Re: Instability in TRUNCATE regression test (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Jun 28, 2006 at 01:13:42PM -0400, Tom Lane wrote: > One thing I was toying with was to add an index to pg_constraint on, > say, (confrelid, conrelid), and to replace the existing seqscans for FK > constraints with scans using this index. The second-column ordering > would guarantee everybody visits the entries in the same order. Not > sure about overall performance implications ... in a small database, > several indexscans might take more time than one seqscan. In a small database, both operations are likely to be plenty fast for TRUNCATE, though. Surely the performance impact of getting the requisite locks would far exceed any catalog scan times, no? And if you were doing TRUNCATE's very often, I'd expect the right pages to be in cache anyway... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: