>
> Considering you're pulling out 450k rows in 8 seconds, I'd also guess
> the data is mostly in memory. Is that normal? Or is this a result of
> having run several test queries against the same data multiple times?
>
Ah yes, that would have been the result of running the query several
times...
>
> > However, this query performs a sequence scan on the table, ignoring
the
> > call_idx13 index (the only difference is the addition of the aspid
field
> > in the order by clause):
>
> You do not have an index which matches the ORDER BY, so PostgreSQL
> cannot simply scan the index for the dat
ECTED]
Sent: Wednesday, July 07, 2004 2:46 PM
To: Joel McGraw
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] query plan wierdness?
The limit is tricking you.
I guess a sequential scan is cheaper than an index scan with the limit
26 found there.
I am wrong?
G
Can someone explain what I'm missing here? This query does what I
expect--it uses the "foo" index on the openeddatetime, callstatus,
calltype, callkey fields:
elon2=# explain analyse select * from call where aspid='123C' and
OpenedDateTime between '2000-01-01 00:00:00.0' and '2004-06-24
23:59:5
