On Sun, May 21, 2006 at 02:01:14PM -0600, Brendan Duddridge wrote:
When the query planner uses the indexes with the concatenated values
and the where clause, the query can be sub-second response times (but
not always depending on the category_id value). By just doing a
regular join as
The problem is that the planner is guessing horribly at what the nodes
will return, and I'm betting the reason for that is your join criteria.
Why are you joining on fields that are concatenated together, instead of
just joining on the fields themselves? That's a sure-fire way to confuse
the
Hi,I have a query that performs WAY better when I have enable_seqscan = off:explain analyze select ac.attribute_id, la.name, ac.sort_order from attribute_category ac, localized_attribute la where ac.category_id = 1001402 and la.locale_id = 101 and ac.is_browsable = 'true' and la.attribute_id =
On sun, 2006-05-21 at 02:21 -0600, Brendan Duddridge wrote:
Hi,
I have a query that performs WAY better when I have enable_seqscan =
off:
explain analyze select ac.attribute_id, la.name, ac.sort_order from
attribute_category ac, localized_attribute la where ac.category_id =
1001402
is there some reason for the complicated form of the
join conditions in the subselect?
Yes, the simpler form query definitely works, but it's not always as
fast as the index version with the complicated join syntax. Although
even that query varies significantly with different category_id
