|Subject||Re: Primary key not used in SELECT|
> This sounds like a compound PK where one (or more) segments have lowselectivity and mass inserts and deletes are being performed without
any follow-up housekeeping. If the PK is getting so out of balance,
it would be expected that dependent FK indexes would suffer the same
kind of deterioration.
>measure? This won't rebuild indexes but it should help to improve the
> How often do you run SET STATISTICS on your indexes as a maintenance
selectivity of these unstable indexes.
>Thanks for the reples, ./heLen and Maxim!
This is a 2 column primary key - id and date - and for most of the
id-s there's only one record and other id-s (about 1%) have 2-3
records with different dates. It seems to me that both id and date
fields have good selectivity.
./heLen, you're right - the table was populated with mass inserts
without any later housekeeping - i've never used SET STATISTICS
At the moment i understand it like this: FB optimizer thought that my
PK index is no good, because index statistics was not up to date?
And assuming my mass inserts were random enough (not sorted by PK
fields) then index doesn't need rebuilding at all?