Re: the big picture for index-only scans - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: the big picture for index-only scans
Date
Msg-id BANLkTinfP7spxXV_J7DfU5Rj8cKWHDb2hA@mail.gmail.com
Whole thread Raw
In response to Re: the big picture for index-only scans  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: the big picture for index-only scans  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2011/5/11 Robert Haas <robertmhaas@gmail.com>:
> On Wed, May 11, 2011 at 3:17 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Completely agree, but why are you saying that to me?
>>
>> When Tom asks me why I suggest something, nobody tells him "its a free
>> software project etc...".
>>
>> What is the difference here?
>
> We're now 40 emails in this thread, and there seems to be far more
> heat than light here.  Here's an attempt at a summary:
>
> - Simon wants proof that the performance benefit of this feature is
> worth any downsides it may have, which is standard procedure, and
> isn't certain the feature will have a significant performance benefit.
> - Numerous other people think Simon's doubts about the feature are
> poorly justified (and some of them also think he's being a pain in the
> neck).
> - Various peripherally related topics, such as optimizing count(*),
> which is not part of the vision for the first go-round that I sketched
> out in my OP, and plan stability, which is another issue entirely,
> have been discussed.
> - Meanwhile, only one person has done any review of the actual code
> that's been written, which is posted on the crash-safe visibility map
> thread, which may be why multiple people seem confused about what it
> does.
> - And no one has done any benchmarking of that code.

Will you be able to do some ? or can you propose a simple process to
do efficient benchmark of the patch ?

If reviewers agree it is safe and benchmarks make evidences that no
basic performance  issue are raised, then let's see if next items have
blockers or can be done.

>
> I think it would be really helpful if some more people would review
> the crash-safe visibility map patch, and if at least one person could
> benchmark it.  It would be useful to know (a) whether that noticeably
> slows down the system during inserts, updates, and deletes, especially
> at very high concurrency; and (b) how much of an impact the additional
> WAL-logging has on VACUUM.  On the other hand, arguing about whether
> index-only scans are going to result in a significant performance
> benefit is not useful.  I am going to be both surprised and
> disappointed if they don't, but there's only one way to find out, and
> a theoretical argument isn't it.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Double ocurring Subplan
Next
From: Alexey Klyukin
Date:
Subject: Re: proposal: a validator for configuration files