Re: [PERFORM] encouraging index-only scans

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] encouraging index-only scans
Date: 2013-09-10 05:09:08
Message-ID: CAA4eK1+mYyJNq09afZ1494pDz-ju2Ox0XmSWMAWbBC41zRRtTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Mon, Sep 9, 2013 at 9:33 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Sun, Sep 8, 2013 at 8:49 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Mon, Sep 9, 2013 at 2:35 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>> I thought it was well known, but maybe I was overly optimistic. I've
>>> considered IOS to be mostly useful for data mining work on read-mostly
>>> tables, which you would probably vacuum manually after a bulk load.
>>>
>>> For transactional tables, I think that trying to keep the vm set-bit
>>> density high enough would be a losing battle. If we redefined the
>>> nature of the vm so that doing a HOT update would not clear the
>>> visibility bit, perhaps that would change the outcome of this battle.
>>
>> Wouldn't it make the Vacuum bit in-efficient in the sense that it will
>> skip some of the pages in which there are only
>> HOT updates for cleaning dead rows.
>
> Maybe. But anyone is competent to clean up dead rows from HOT
> updates, it is not exclusively vacuum that can do it, like it is for
> non-HOT tuples.

Yes, that is right, but how about freezing of tuples, delaying that
also might not be good. Also it might not be good for all kind of
scenarios that always foreground operations take care of cleaning up
dead rows leaving very less chance for Vacuum (only when it has to
scan all pages aka anti-wraparound vacuum) to cleanup dead rows.

If we are sure that Vacuum skipping pages in a database where there
are less non-HOT updates and deletes (or mostly inserts and
Hot-updates) is not having any significant impact, then it can be
quite useful for IOS.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Prabakaran, Vaishnavi 2013-09-10 06:09:11 Proposal - Support for 'OR REPLACE' in 'CREATE TRIGGER' command
Previous Message Boszormenyi Zoltan 2013-09-10 04:51:37 Re: ECPG FETCH readahead

Browse pgsql-performance by date

  From Date Subject
Next Message Mel Llaguno 2013-09-10 05:43:16 Re: Performance bug in prepared statement binding in 9.2?
Previous Message Bruce Momjian 2013-09-10 02:16:44 Re: Performance bug in prepared statement binding in 9.2?