From: | Rosser Schwarz <rosser(dot)schwarz(at)gmail(dot)com> |
---|---|
To: | Francisco Reyes <lists(at)natserv(dot)com> |
Cc: | PostgreSQL performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Understanding explains |
Date: | 2004-10-11 22:03:07 |
Message-ID: | 37d451f70410111503755fb751@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
while you weren't looking, Francisco Reyes wrote:
> Is there any disadvantage of having the enable_seqscan off?
Plenty.
The planner will choose whichever plan looks "cheapest", based on the
information it has available (table size, statistics, &c). If a
sequential scan looks cheaper, and in your case above it clearly is,
the planner will choose that query plan. Setting enable_seqscan =
false doesn't actually disable sequential scans; it merely makes them
seem radically more expensive to the planner, in hopes of biasing its
choice towards another query plan. In your case, that margin made an
index scan look less expensive than sequential scan, but your query
runtimes clearly suggest otherwise.
In general, it's best to let the planner make the appropriate choice
without any artificial constraints. I've seen pathalogical cases
where the planner makes the wrong choice(s), but upon analysis,
they're almost always attributable to poor statistics, long
un-vacuumed tables, &c.
/rls
--
:wq
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-10-11 23:52:14 | TestPerf Project started |
Previous Message | Tom Lane | 2004-10-11 21:33:57 | Re: Normal case or bad query plan? |