On Wed, 2003-07-02 at 10:24, Michael Mattox wrote:
> > Try this:
>
> Rod, you improved my query last week (thank you very much) but I'm not sure
> why but my performance is getting worse. I think I know what happened, when
> I did my load testing I created data that all had the same date, so sorting
> on the date was very fast. But now I've been running the system for a few
> weeks I've got a range of dates and now the sort is very costly. I'm
> curious if it's possible to optimize this with an index? I've tried
> creating some indexes but they're never used.
Standard questions, did you VACUUM? Regularly? Want to try again and
send us the output from VACUUM VERBOSE?
Sounds like you created a ton of test data, then removed a bunch? Did
you REINDEX that table?
During normal use, what is your query spread like? Mostly selects with
some inserts? Any updates or deletes? How often to updates or deletes
come in, and how many rows do they effect?
> -> Index Scan using monitorstatusxmonitori on
> monitorstatusx ms (cost=0.00..5996.18 rows=163 width=84) (actual
> time=4383.38..14936.39 rows=225 loops=1)
> Index Cond: ("outer".jdoidx = ms.monitorx)
> Filter: ((datex >= '2003-07-01
> 00:00:00'::timestamp without time zone) AND (datex <= '2003-07-01
> 23:59:59'::timestamp without time zone))
The above index scan is taking a vast majority of the time (nearly 15
seconds of the 16 second total -- stop thinking about sorts!).. What
happened to the index on monitorx and datex?
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
