2011/5/11 Robert Haas <robertmh...@gmail.com>: > On Wed, May 11, 2011 at 3:17 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
