Aaron,
> This database gets a monthly update and it read only until the next
> update. I ANALYZE once after each update. Since the data does not
> change I should not need to ANALYZE again afterwards.
Actually, if the database is read-only between updates, you should:
ANALYZE
VACUUM FULL F
I am running pg 7.2 the PG reference build.
Thanks for the ANALYZE tip, it led me to a answer.
This database gets a monthly update and it read only until the next
update. I ANALYZE once after each update. Since the data does not
change I should not need to ANALYZE again afterwards.
I menti
Aaron,
> # SET enable_seqscan to FALSE ;
> forced the use of an Index and sped things up greatly.
>
> I am not sure why it made the switch. The load on the server seems to
> affect the performance, but I am seeing it more on the production server
> with 100 million rows as oppose
Thanks,
Changing '0/19/01' to '0/19/01'::date gave me a subjective 50% speedup.
A ran a bunch of queries w/ explain and I noticed that some
combinations did not use the indexes and went right to seq scan. All of
the where clause args are indexed.
# SET enable_seqscan
On Wed, 18 Sep 2002, Aaron Held wrote:
> I am running into a serious performance issue with some basic queries.
>
> If I run something like
>
>select * from "Calls" WHERE
> ( ("CallType" = 'LONG DIST' ))
>
> The search takes about 15 seconds
>
> if I run
> select * from "C
I am running into a serious performance issue with some basic queries.
If I run something like
select * from "Calls" WHERE
( ("CallType" = 'LONG DIST' ))
The search takes about 15 seconds
if I run
select * from "Calls" WHERE
( ( "DateOfCall"='06/19/02') )
