"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> So is a multi-column index really just two separate indexes with a
> constraint added if necessary? I guess I had an idea in my head that it
> would be something like an index on the concatenation of the two fields.
Well, it *is* an index on the con
Tom Lane wrote:
> The only reason the planner should choose a single-column index over
> using the first column of a multi-column index is that the latter index
> is likely to be physically larger and thus require more I/O to access.
> So, there's no penalty in the cost calculations other than the
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
>> That seems strange to me also, particularly if the index column ordering
>> is indeed actor_id,case_id and not the other way round
> Actually, it *is* the other way around- I didn't realize that could make a
> difference.
Ah. Okay, that eliminate
> That seems strange to me also, particularly if the index column ordering
> is indeed actor_id,case_id and not the other way round
Tom-
Actually, it *is* the other way around- I didn't realize that could make a
difference. Here's the line that creates it:
create unique index actor_case_assign
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> The part that looks wrong to me is that on the last line of the explain, it
> is using the index "actor_case_assignment_both" (the index on
> actor_id,case_id) even though actor_id is never referenced in this query and
> and index on case_id alone is
Hi-
I'm trying to squeeze better performance out of a query, but the explain
returns a plan that really puzzles me.
A little background is in order- the table that I think is central to my
problem is what I call an "assignment table" I'm working with court data, so
I have people and cases. A per
