On Jan 27, 2007, at 5:56 PM, Tom Lane wrote:
I've committed a fix for 8.2.2, but in the meantime maybe you could
change your varchar column to text?
regards, tom lane
Thank you for the help and the fix. We're just performance testing
right now so minor data model chan
Ryan Holmes <[EMAIL PROTECTED]> writes:
> So, yes, disabling seqscan does force an index scan for the IN
> version. My question now is, how do I get PostgreSQL to make the
> "right" decision without disabling seqscan?
I pinged you before because in a trivial test case I got
indexscans out of b
On Jan 27, 2007, at 3:53 PM, Tom Lane wrote:
Ryan Holmes <[EMAIL PROTECTED]> writes:
I have a relatively simple query where the planner chooses a
sequential scan when using the IN operator but chooses an index scan
when using logically equivalent multiple OR expressions.
EXPLAIN ANALYZE for
Ryan Holmes <[EMAIL PROTECTED]> writes:
> I have a relatively simple query where the planner chooses a
> sequential scan when using the IN operator but chooses an index scan
> when using logically equivalent multiple OR expressions.
EXPLAIN ANALYZE for both, please?
If you set enable_seqscan
PostgreSQL version: 8.2.1
OS: Windows Server 2003
I have a relatively simple query where the planner chooses a
sequential scan when using the IN operator but chooses an index scan
when using logically equivalent multiple OR expressions. Here is the
table structure and the two versions of th
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 analyzed
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 f
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 record
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,
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 int8_col
>
> 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?
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 exten
12 matches
Mail list logo
