From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Michael Nolan <htfoot(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New/Revised TODO? Gathering actual read performance data for use by planner |
Date: | 2011-05-25 16:18:53 |
Message-ID: | BANLkTik61Cb6W_1PjUAfUMoyiumsZ9X+FA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 25, 2011 at 10:17 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> This data would probably need to be kept separately for each table or
>> index, as some tables or indexes
>> may be mostly or fully in cache or on faster physical media than others,
>> although in the absence of other
>> data about a specific table or index, data about other relations in the
>> same tablespace might be of some use.
>
> This is the important part. Model how the data needs to get stored such
> that the optimizer can make decisions using it, and I consider it easy to
> figure out how it will get populated later.
I basically agree. There have been several recent discussions of this
topic on both -hackers and -performance; it is likely that the TODO
needs to be updated with some more recent links.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-25 16:20:44 | Re: Pull up aggregate subquery |
Previous Message | Robert Haas | 2011-05-25 16:17:11 | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |