On Fri, Jun 5, 2009 at 7:32 PM, Josh Berkus wrote:
> My first thought would be to increase statistics dramatically on the
> filtered columns in hopes of making PG realize there's a lot of rows there;
> it's off by 8x. Correlations stats are an ongoing issue in PostgreSQL.
I started at a stats_ta
On Mon, May 25, 2009 at 11:22 AM, David Blewett wrote:
> On Sun, May 24, 2009 at 2:42 PM, Tom Lane wrote:
>>
>> It still feels like this schema design is obscuring correlations that
>> the planner needs to know about in order to make decent estimates.
>
> I'm
On Sun, May 24, 2009 at 2:42 PM, Tom Lane wrote:
>
> It still feels like this schema design is obscuring correlations that
> the planner needs to know about in order to make decent estimates.
I'm not sure how to make the planner aware of these correlations. Is there
something inherently flawed w
On Sat, May 9, 2009 at 11:52 AM, Tom Lane wrote:
> David Blewett writes:
> > On Fri, May 8, 2009 at 10:00 PM, Tom Lane wrote:
> >> Thanks. Could I trouble you for one other data point --- about how many
> >> rows are in each of these tables?
>
> > Not a
On Sat, May 9, 2009 at 11:52 AM, Tom Lane wrote:
> As best I can tell, the selectivity numbers are about what they should
> be --- for instance, using these stats I get a selectivity of 0.074
> for the join clause fkr.submission_id = tr.submission_id. Over the
> entire relations (646484 and
On Fri, May 8, 2009 at 10:00 PM, Tom Lane wrote:
> Thanks. Could I trouble you for one other data point --- about how many
> rows are in each of these tables?
Not a problem:
canvas_dateresponse 263819
canvas_foreignkeyresponse 646484
canvas_integerresponse 875375
canvas_submission
On Thu, May 7, 2009 at 6:44 PM, Tom Lane wrote:
> Look into pg_stats for the rows concerning the columns used in the
> query's WHERE and JOIN/ON clauses.
Okay, here you go:
http://rafb.net/p/20y8Oh72.html
David
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To ma
On Thu, May 7, 2009 at 4:31 PM, Tom Lane wrote:
> as few as ten rows out, it'd likely switch to a different plan. So the
> So the question to ask is why the rowcount estimates are so abysmally bad.
> You mentioned having tried to increase the stats targets, but without
> seeing the actual stats d
On Thu, May 7, 2009 at 12:53 PM, David Blewett wrote:
> 1. http://dpaste.com/hold/41842/
> 2. http://explain.depesz.com/s/Wg
> 3. http://explain.depesz.com/s/1s
> 4. http://dpaste.com/hold/41846/
Forgot to mention that I'm using Postgres 8.3.6 on linux 2.6.24.
Shared buffe
query completes in around 3-5s. With them enabled, it
takes anywhere from 45 to 60 seconds. Here is the DDL for the tables
and the month_last_day function [4].
Any help would be appreciated!
David Blewett
1. http://dpaste.com/hold/41842/
2. http://explain.depesz.com/s/Wg
3. http://explain.depesz.com/s
10 matches
Mail list logo
