Re: Optimization for lazy_scan_heap

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimization for lazy_scan_heap
Date: 2016-09-06 16:47:49
Message-ID: CA+TgmoZVM73Sv+88qoP7wdMn-Yy+TMA58aCZb9oH8C5Q=RVX1g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 5, 2016 at 8:57 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> What performance difference does this make, in a realistic use case?
>
> I have yet to measure performance effect but it would be effect for
> very large frozen table.

I think if you are proposing this patch because you think that the
existing code won't perform well, you definitely need to submit some
performance results showing that your approach is better. If you
can't show that your approach is practically better (rather than just
theoretically better), then I'm not sure we should change anything.
It's very easy to screw up the code in this area and we do not want to
risk corrupting data for the sake of an optimization that isn't really
needed in the first place.

Of course, if you can prove that the change has a significant benefit,
then it's definitely worth considering.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2016-09-06 16:48:31 Re: WIP: Covering + unique indexes.
Previous Message Robert Haas 2016-09-06 16:42:25 Re: Vacuum: allow usage of more than 1GB of work mem