Re: Planner problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mikael Kjellström <mikael(dot)kjellstrom(at)mksoft(dot)nu>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Planner problem
Date: 2004-06-04 14:41:50
Message-ID: 27262.1086360110@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

=?ISO-8859-1?Q?Mikael_Kjellstr=F6m?= <mikael(dot)kjellstrom(at)mksoft(dot)nu> writes:
> I am having a bit of problem with the plan that the planner produces.

Actually, your problem is with the row-count estimates. Some of them
are pretty wildly off, which inevitably leads to bad plan choices.
In particular the price row estimate is off by a factor of 200 in all
three plans:

> -> Index Scan using priceix2 on price (cost=0.00..3.41 rows=23 width=20) (actual time=0.042..25.811 rows=4402 loops=111)
> Index Cond: ('2004-06-01'::date <= validstopdate)
> Filter: (('2004-06-01'::date >= validstartdate) AND (deletiondate IS NULL) AND (organizationid = 1))

> -> Index Scan using priceix2 on price (cost=0.00..3.41 rows=23 width=20) (actual time=0.053..26.225 rows=4402 loops=1)
> Index Cond: ('2004-06-01'::date <= validstopdate)
> Filter: (('2004-06-01'::date >= validstartdate) AND (deletiondate IS NULL) AND (organizationid = 1))

> -> Index Scan using priceix2 on price (cost=0.00..3.41 rows=23 width=20) (actual time=0.050..26.475 rows=4402 loops=1)
> Index Cond: ('2004-06-01'::date <= validstopdate)
> Filter: (('2004-06-01'::date >= validstartdate) AND (deletiondate IS NULL) AND (organizationid = 1))

and priceavailable is off by a factor of 100:

> -> Index Scan using priceavailableix1 on priceavailable pa (cost=0.00..5.91 rows=1 width=16) (actual time=0.067..4.182 rows=111 loops=1)
> Index Cond: (pa.locationconnectionid = "outer".locationconnectionid)
> Filter: (((direction = 'D'::text) OR (direction = 'B'::text)) AND (deletiondate IS NULL))

> -> Index Scan using priceavailableix1 on priceavailable pa (cost=0.00..141.57 rows=43 width=16) (actual time=0.048..48.739 rows=6525 loops=1)
> Filter: (((direction = 'D'::text) OR (direction = 'B'::text)) AND (deletiondate IS NULL))

> -> Index Scan using priceavailableix1 on priceavailable pa (cost=0.00..5.91 rows=1 width=16) (actual time=0.070..0.965 rows=111 loops=1)
> Index Cond: (pa.locationconnectionid = "outer".locationconnectionid)
> Filter: (((direction = 'D'::text) OR (direction = 'B'::text)) AND (deletiondate IS NULL))

Are you sure you've vacuum analyzed these two tables recently? If so,
what may be needed is to increase ANALYZE's statistics target for
the columns used in the conditions. (See ALTER TABLE SET STATISTICS)

I suspect that part of the story here has to do with cross-column
correlations, which the present planner will never figure out since it
has no cross-column statistics. But it's hard to believe that that's
the problem for cases as simple as

> Filter: (((direction = 'D'::text) OR (direction = 'B'::text)) AND (deletiondate IS NULL))

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-06-04 15:33:29 Re: filesystem option tuning
Previous Message CH 2004-06-04 14:21:11 Re: filesystem option tuning