"Dave Golombek" <[EMAIL PROTECTED]> writes:
> Ah, I forgot to try the index on the base table using 8.2, which does indeed
> solve the problem. It unfortunately doesn't help with 8.1.4, which we have
> in the field; any thoughts on workarounds for older versions or should I
> just use a function un
Tom Lane writes:
> "Dave Golombek" <[EMAIL PROTECTED]> writes:
> > Is there a way I can reformulate the query to help the planner use the
> > indices?
>
> Use 8.2. Also put an index on the base table, not only the children ---
> the forced seqscan on the base weighs down the cost estimate for the
Dave Golombek wrote:
create table base (file integer, data integer);
create table child_0 () inherits (base);
create table child_1 () inherits (base);
create index child_0_file_index on child_0 using btree (file);
create index child_1_file_index on child_1 using btree (file);
create table other
"Dave Golombek" <[EMAIL PROTECTED]> writes:
> Is there a way I can reformulate the query to help the planner use the
> indices?
Use 8.2. Also put an index on the base table, not only the children ---
the forced seqscan on the base weighs down the cost estimate for the
plan you would like to have.
I have a query which runs a join between a table with multiple child tables
and a second table. The planner is doing a sequential scan of the children,
then doing the join on the result, despite having indices that are relevant.
If I do the join between any of the children and the second table, the
