From: | Jaime Casanova <systemguards(at)gmail(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: generalizing the planner knobs |
Date: | 2005-12-08 17:35:25 |
Message-ID: | c2d9e70e0512080935m24823f9eke50dff8c2bacb3c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> BTW, there's another end to the 'enable_seqscan=false' problem... it
> sometimes doesn't work! Last I looked, enable_seqscan=false only added a
> fixed overhead cost to a seqscan (1000000 IIRC). The problem is, some
> queries will produce estimates for other methodes that are more
> expensive than a seqscan even with the added burden. If instead of
> adding a fixed amount enable_seqscan=false multiplied by some amount
> then this would probably be impossible to occur.
>
> (And before someone asks, no, I don't remember which query was actually
> faster...)
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>
I have often considered that this is an indication that seq scan is
actually the better plan... although, i have to admit that is a little
confusing that enable_seqscan = false actually let you use a seqscan
if the other plans are bad enough
--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-08 17:36:30 | Re: Reducing contention for the LockMgrLock |
Previous Message | Greg Stark | 2005-12-08 17:27:35 | Re: Reducing contention for the LockMgrLock |