| From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
|---|---|
| To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: generalizing the planner knobs |
| Date: | 2005-12-08 05:35:45 |
| Message-ID: | 20051208053545.GI16053@nasby.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 01, 2005 at 12:32:12PM -0500, Qingqing Zhou wrote:
>
> "Neil Conway" <neilc(at)samurai(dot)com> wrote
> >
> > This would also be useful when diagnosing bad query plans: for example,
> > setting enable_seqscan=false often causes the planner to disregard the
> > use of *any* sequential scan, anywhere in the plan. The ability to
> > slightly bump up the cost of particular operations would allow more
> > alternative plans to be examined.
> >
>
> This method also has the problem of "enable_seqscan=false" in some
> situations. I would vote we implement the final general solution like query
> plan hints directly.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-12-08 05:59:47 | Re: Vertical Partitioning with TOAST |
| Previous Message | Jim C. Nasby | 2005-12-08 05:02:27 | Re: Vertical Partitioning with TOAST |