From: | "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 7.2.1 optimises very badly against 7.2 |
Date: | 2002-07-12 08:54:49 |
Message-ID: | D38A0FCD5830E848992DF2D4AF5F6F4F7306C8@conwy.leeds.ananova.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 10 July 2002 15:01
> To: Sam Liddicott
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] 7.2.1 optimises very badly against 7.2
>
> If we could get by with a rule as simplistic as "never use a
> seqscan if you can avoid it" then the planner could be a lot simpler.
> Your real gripe is that the planner is overestimating the costs of
> indexscans relative to seqscans; that would be more appropriately
> addressed by lowering random_page_cost a little than by getting out
> the sledgehammer.
>
> A more practical reason not to do that is that in situations where a
> seqscan is not avoidable, enable_seq_scan = OFF is likely to cause the
> planner to make bad choices, since the disable cost will swamp out all
> the actually-useful cost judgments.
Right. Do you feel the random page cost of 3 is good to solve this?
Is it solely a tuning problem at my end, or do you want to do further tests
to derive a better default value?
Sam
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian 'Dagurashibanipal' von Bidder | 2002-07-12 09:02:26 | Re: What is better any why |
Previous Message | Thirumoorthy Bhuvneswari | 2002-07-12 08:54:11 | Re: Query Speed!!! |