From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Martin Marques" <martin(at)bugs(dot)unl(dot)edu(dot)ar> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Bitmap Heap scan 8.1/8.2 |
Date: | 2007-10-23 12:32:51 |
Message-ID: | 162867790710230532m1504601fha41a933de97ffdad@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2007/10/23, Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar>:
> Martin Marques escribió:
> > Pavel Stehule wrote:
> >>
> >> try
> >>
> >> set work_mem to '8MB';
> >> and
> >> explain analyze select ..
> >
> > These things didn't help. What changed the plan completely was this:
> >
> > seq_page_cost = 5.0 # measured on an arbitrary scale
> > cpu_tuple_cost = 0.05 # same scale as above
>
> Can someone explain how this parameters are measured? What is 5.0 in
> this case for seq_page_cost?
>
http://www.postgresql.org/docs/8.2/interactive/runtime-config-query.html
5.0 means so seq scan will be expensive for optimaliser, and
optimaliser will prefer index scan.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-10-23 12:37:01 | Re: Reliability of WAL replication |
Previous Message | Nis Jørgensen | 2007-10-23 12:18:20 | Re: SQL spec/implementation question: UPDATE |