From: Csaba Nagy <nagy@ecircle-ag.com>
To: Kenneth Marshall <ktm@rice.edu>
Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Searching for the cause of a bad plan
Date: Fri, 28 Sep 2007 14:33:52 +0200
Message-ID: <1190982832.5430.94.camel@PCD12478> (raw)
In-Reply-To: <20070928122556.GH14440@it.is.rice.edu>
References: <1190399879.4202.127.camel@ebony.site>
<27857.1190417434@sss.pgh.pa.us>
<1190640429.4181.165.camel@ebony.site>
<1190818357.5430.29.camel@PCD12478>
<21582.1190820137@sss.pgh.pa.us>
<1190894004.5430.46.camel@PCD12478>
<29186.1190904025@sss.pgh.pa.us>
<1190906166.5430.76.camel@PCD12478>
<46FBF174.1020206@cheapcomplexdevices.com>
<1190967130.5430.85.camel@PCD12478>
<20070928122556.GH14440@it.is.rice.edu>
> Just an idea, but with the 8.3 concurrent scan support would it be
> possible to hang a more in depth analyze over exisiting sequential
> scans. Then it would be a lower cost to have higher resolution in
> the statistics because the I/O component would be hidden.
The biggest problem with that is that it wouldn't be deterministic...
the table in question from my original post is never scanned
sequentially in normal operation. The other way around is also possible,
when sequential scans are too frequent, in that case you wouldn't want
to also analyze all the time. So there would be a need for logic of when
to analyze or not with a sequential scan and when do it proactively
without waiting for one... and I'm not sure it will be worth the
complexity.
I think it would me much more productive if some "long running query"
tracking combined with a "background planner" thread would do targeted
analyzes for specific correlations/distributions/conditions based on
what queries are actually running on the system.
Cheers,
Csaba.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: nagy@ecircle-ag.com, ktm@rice.edu, rm_pg@cheapcomplexdevices.com
Subject: Re: Searching for the cause of a bad plan
In-Reply-To: <1190982832.5430.94.camel@PCD12478>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox