Re: the big picture for index-only scans

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: the big picture for index-only scans
Date: 2011-05-13 22:34:24
Message-ID: BANLkTinfP7spxXV_J7DfU5Rj8cKWHDb2hA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/5/11 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, May 11, 2011 at 3:17 AM, Simon Riggs <simon(at)2ndquadrant(dot)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(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Klyukin 2011-05-13 22:49:31 Re: proposal: a validator for configuration files
Previous Message Tom Lane 2011-05-13 22:02:16 Re: Double ocurring Subplan