Brian,
I hate to nag, but could anybody help me with this? We have a few related queries that are causing noticeable service delays in our production system. I've tried a number of different things, but I'm running out of ideas and don't know what to do next.
For some reason, your first post didn't make it to the list, which is why nobody responded.
I've got a query on our production system that isn't choosing a good plan. I can't see why it's choosing to do a sequential scan on the ItemExperienceLog table. That table is about 800mb and has about 2.5 million records. This example query only returns 4 records. I've tried upping the statics for ItemExperienceLog.VistorId and ItemExperienceLog.ItemId to 1000 (from out default of 100) with no success.
Yes, that is kind of inexplicable. For some reason, it's assigning a very high cost to the nestloops, which is why it wants to avoid them with a seq scan. Can you try lowering cpu_index_cost to 0.001 and see how that affects the plan?
--Josh -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
