Re: [WIP] cache estimates, cache access cost - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [WIP] cache estimates, cache access cost
Date
Msg-id BANLkTikO-M0eBqg0AXynZ+Dq0gdNWUvcbQ@mail.gmail.com
Whole thread Raw
In response to [WIP] cache estimates, cache access cost  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Responses Re: [WIP] cache estimates, cache access cost
Re: [WIP] cache estimates, cache access cost
Re: [WIP] cache estimates, cache access cost
List pgsql-hackers
On Tue, Jun 14, 2011 at 10:29 AM, Cédric Villemain
<cedric.villemain.debian@gmail.com> wrote:
> 0001-Add-reloscache-column-to-pg_class.patch
> 0002-Add-a-function-to-update-the-new-pg_class-cols.patch
> 0003-Add-ANALYZE-OSCACHE-VERBOSE-relation.patch
> 0004-Add-a-Hook-to-handle-OSCache-stats.patch
> 0005-Add-reloscache-to-Index-Rel-OptInfo.patch
> 0006-Add-cache_page_cost-GUC.patch

It seems to me that posting updated versions of this patch gets us no
closer to addressing the concerns I (and Tom, on other threads)
expressed about this idea previously.  Specifically:

1. ANALYZE happens far too infrequently to believe that any data taken
at ANALYZE time will still be relevant at execution time.
2. Using data gathered by ANALYZE will make plans less stable, and our
users complain not infrequently about the plan instability we already
have, therefore we should not add more.
3. Even if the data were accurate and did not cause plan stability, we
have no evidence that using it will improve real-world performance.

Now, it's possible that you or someone else could provide some
experimental evidence refuting these points.  But right now there
isn't any, and until there is, -1 from me on applying any of this.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ITYM DROP TABLE
Next
From: Robert Haas
Date:
Subject: Re: use less space in xl_xact_commit patch