Re: Vacuum: allow usage of more than 1GB of work mem

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum: allow usage of more than 1GB of work mem
Date: 2016-09-08 14:35:29
Message-ID: edde8061-2900-b0b7-7120-7c77d2ddc0e2@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2016-09-08 14:44:05 Re: Patch: Implement failover on libpq connect level.
Previous Message Jim Nasby 2016-09-08 14:27:19 Re: Optimization for lazy_scan_heap