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.
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
