Re: 7.2.1 optimises very badly against 7.2
От | Sam Liddicott |
---|---|
Тема | Re: 7.2.1 optimises very badly against 7.2 |
Дата | |
Msg-id | D38A0FCD5830E848992DF2D4AF5F6F4F7306C8@conwy.leeds.ananova.internal обсуждение исходный текст |
Ответ на | 7.2.1 optimises very badly against 7.2 ("Sam Liddicott" <sam.liddicott@ananova.com>) |
Ответы |
Re: 7.2.1 optimises very badly against 7.2
|
Список | pgsql-general |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 10 July 2002 15:01 > To: Sam Liddicott > Cc: pgsql-general@postgresql.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
В списке pgsql-general по дате отправления: