Re: Tuning random_page_cost - Mailing list pgsql-general

From Markus Wollny
Subject Re: Tuning random_page_cost
Date
Msg-id 2266D0630E43BB4290742247C891057505AFCCDA@dozer.computec.de
Whole thread Raw
In response to Tuning random_page_cost  ("Markus Wollny" <Markus.Wollny@computec.de>)
List pgsql-general
Thanks, that seems to have done the trick :)

> -----Ursprüngliche Nachricht-----
> Von: Bruno Wolff III [mailto:bruno@wolff.to]
> Gesendet: Dienstag, 13. Juli 2004 14:44
> An: Markus Wollny
> Cc: pgsql-general@postgresql.org
> Betreff: Re: [GENERAL] Tuning random_page_cost
>
> On Tue, Jul 13, 2004 at 13:30:29 +0200,
>   Markus Wollny <Markus.Wollny@computec.de> wrote:
> > Hi!
> >
> > I've got a query that has a where clause on a timestamp field:
> >
> > select  t.board_id
> >    , t.thread_id
> >  from  public.board_thread t
> >  where  t.last_reply <= now()-'6 months'::interval
> >  limit  1
> >
> > I've got random_page_cost set to 1.4 which is fine for most
> queries;
> > yet here the planner prefers a (slower) sequential scan:
>
> If you know that an index scan is better you can fudge the
> query to change the planner's estimate of the number of rows
> that will be returned.
> The normal fudge is to add a >= check for some timestamp that
> is earlier than any in the column, so that you will have a
> range condition, but not any change in the rows returned.
>

pgsql-general by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Tuning random_page_cost
Next
From: "Florian G. Pflug"
Date:
Subject: Re: (Again) Datacorruption using 7.4.2 on XFS/raid1