Forum OpenACS Development: Re: acs_object__new slowness...

Collapse
Posted by Don Baccus on
Man, you've hit something here ...

The execution plan my installation's using is very similar, if not identical, to the last one you've posted that runs in 1MS on your machine (my eyes cross whenever I try to verify it's actually identical :)

How much buffer space do you have allocated?  (-B from the postmaster command line or set in your PG startup control file)

I'm wondering if you might not be disk thrashing?  That index scan does seem to be where the time is being spent, looking at your original explain with timing info.

Then again it may just be the fact that you've materialized the view.

Very strange ...

I think the view can be rewritten using "not exists" and that seems to generate a slightly nicer plan than the one above but I need to test to make sure my rewrite is actually equivalent ...

Collapse
Posted by Jeff Davis on
It could be thrashing I suppose. I have shared_buffers and 8192 (64MB) which is not as large as it could be (although I intentionally set it a little low since I want to catch performance problems where the db does not fit in memory). I will bump it up and see if it makes a difference.

Maybe we should drop the container_id index since I don't think it ever has particularly a particularly good key distribution and so is hardly ever better than a table scan (it's got 2 distinct values on openacs.org).

Even on sloanspace the two big container_id's make up 35% of the rows in group_element_index.

Do we ever really query on container_id w/o also having a group_id?

Collapse
Posted by Jeff Davis on
I bumped shared_buffers up to 256mb timed it w/o the index (.56ms first time, .26ms once things were cached), recreated the index and timed it again 1st time through 1198ms, 5th time through 1149ms so no probably not caching.

I dropped the index and the query was back to .38ms.

I vote do away with the index.