On 27.01.2007, at 00:35, Russell Smith wrote:
Guess 1 would be that your primary key is int8, but can't be
certain that is what's causing the problem.
Why could that be a problem?
cug
---(end of broadcast)---
TIP 3: Have you checked our
Hi,
I find various references in the list to this issue of queries
being too slow because the planner miscalculates things and
decides to go for a sequenctial scan when an index is available
and would lead to better performance.
Is this still an issue with the latest version? I'm
Guido Neitzer wrote:
On 27.01.2007, at 00:35, Russell Smith wrote:
Guess 1 would be that your primary key is int8, but can't be certain
that is what's causing the problem.
Why could that be a problem?
Before 8.0, the planner would not choose an index scan if the types were
different
On Sat, 2007-01-27 at 21:44 +1100, Russell Smith wrote:
Guido Neitzer wrote:
On 27.01.2007, at 00:35, Russell Smith wrote:
Guess 1 would be that your primary key is int8, but can't be certain
that is what's causing the problem.
Why could that be a problem?
Before 8.0, the planner
Tomas Vondra wrote:
When I force it via set enable_seqscan to off, the index scan
takes about 0.1 msec (as reported by explain analyze), whereas
with the default, it chooses a seq. scan, for a total execution
time around 10 msec!! (yes: 100 times slower!). The table has
20 thousand
Carlos Moreno [EMAIL PROTECTED] writes:
But I think the problem is that this particular table had not been
vacuum analyzed after having inserted the 2 records (the
query planner was giving me seq. scan when the table had about
a dozen records --- and seq. scan was, indeed, 10 times
Tom Lane wrote:
One reason you might consider updating is that newer versions check the
physical table size instead of unconditionally believing
pg_class.relpages/reltuples. Thus, they're much less likely to get
fooled when a table has grown substantially since it was last vacuumed
or
Carlos Moreno skrev:
When I force it via set enable_seqscan to off, the index scan
takes about 0.1 msec (as reported by explain analyze), whereas
For the time being, I'm using an explicit enable_seqscan off
in the client code, before executing the select. But I wonder:
Is this still an
Carlos Moreno wrote:
Hi,
I find various references in the list to this issue of queries
being too slow because the planner miscalculates things and
decides to go for a sequenctial scan when an index is available
and would lead to better performance.
Is this still an issue with the latest
