Re: Vacuum: allow usage of more than 1GB of work mem
От | Jim Nasby |
---|---|
Тема | Re: Vacuum: allow usage of more than 1GB of work mem |
Дата | |
Msg-id | edde8061-2900-b0b7-7120-7c77d2ddc0e2@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Vacuum: allow usage of more than 1GB of work mem (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On 9/8/16 3:48 AM, Masahiko Sawada wrote: > If we replaced dead_tuples with an array-of-array, isn't there > negative performance impact for lazy_tid_reap()? > As chunk is added, that performance would be decrease. Yes, it certainly would, as you'd have to do 2 binary searches. I'm not sure how much that matters though; presumably the index scans are normally IO-bound? Another option would be to use the size estimation ideas others have mentioned to create one array. If the estimates prove to be wrong you could then create a single additional segment; by that point you should have a better idea of how far off the original estimate was. That means the added search cost would only be a compare and a second pointer redirect. Something else that occurred to me... AFAIK the only reason we don't support syncscan with VACUUM is because it would require sorting the TID list. If we just added a second TID list we would be able to support syncscan, swapping over to the 'low' list when we hit the end of the relation. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
В списке pgsql-hackers по дате отправления: