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 planne
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
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
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 =
>
