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 =
>
DW,
> The idea of the control is, of course, to subtract the overhead of
> the benchmarking function from the code actually being tested. So I
> guess my question is, how important is it to have the control there,
> and, if it is important, how should it actually work?
Well, per our convers
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 May 21, 2006, at 12:23, Josh Berkus wrote:
Well, per our conversation the approach doesn't really work. EXECUTE
'string' + generate_series seems to carry a substantial and
somewhat random
overhead, between 100ms and 200ms -- enough to wipe out any
differences
between queries.
Per our
