Re: Random Page Cost and Planner

From: David Jarvis <thangalin(at)gmail(dot)com>
To: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
Cc: Bryan Hinton <bryan(at)bryanhinton(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Random Page Cost and Planner
Date: 2010-05-27 15:55:55
Message-ID: AANLkTinAhrwwwQKh6NrX-nnvcpxT1EFFlZrUxhaDB87C@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Salut, Cédric.

I wonder what the plan will be if you replace sc.taken_* in :
> m.taken BETWEEN sc.taken_start AND sc.taken_end
> by values. It might help the planner...
>

That is a fairly important restriction. I will try making it *
(year1||'-01-01')::date*, but I have no constant value for it -- it is a
user-supplied parameter. And then there's the year wrapping problem, too,
where the ending year will differ from the starting year in certain cases.
(Like querying rows between Dec 22, 1900 to Mar 22 *1901* rather than Mar 22
1900 to Dec 22 1900. The first query is the winter season and the second
query is all seasons except winter.)

> Also, I'll consider explicit ordered join but I admit I haven't read
> the whole thread (in particular the table size).
>

C'est une grosse table. Pres que 40 million lines; il y a sept tableau comme
ca.

I tried an explicit join in the past: it did not help much. But that was
before everything was running this fast, so now that the system performs
differently, maybe it will help?

Dave

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message alvherre 2010-05-27 16:10:20 Re: Autovacuum in postgres.
Previous Message Craig Ringer 2010-05-27 15:55:13 Re: Query timing increased from 3s to 55s when used as function instead of select