Re: Optimizer not using index on 120M row table

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: Optimizer not using index on 120M row table
Дата
Msg-id 1049781870.3145.118.camel@tokyo
обсуждение исходный текст
Ответ на Re: Optimizer not using index on 120M row table  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: Optimizer not using index on 120M row table
Список pgsql-general
On Tue, 2003-04-08 at 00:35, Jim C. Nasby wrote:
> On Tue, Apr 08, 2003 at 12:29:00AM -0400, Neil Conway wrote:
> > Storing visibility information in index entries (in addition to heap
> > tuples) doesn't strike me as a good idea: for one thing, an
> > UPDATE/DELETE would require touching both heap tuples and any index
> > entries that point to them. It would also bloat the size of indexes.
>
> True, though these could require touching the indexes anyway due to the
> data changes (or at least I assume so, given how other RDBMS's work).

Not in the case of DELETE (since you don't need to add a new index
entry, and the logic to determine whether a tuple is deleted is based
upon the visibility information stored in the heap). In the case of
UPDATE, chances are that the index entry you need to add for the new
version of the tuple isn't on the same page as the old one -- so the
fact that the two pages happen to belong to the same index doesn't
really help.

> It might be a useful option to allow

Indeed, I can see how some might find it useful. Perhaps you'd like to
implement it? :-)

Cheers,

Neil


В списке pgsql-general по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: Age function
Следующее
От: "J. M. Brenner"
Дата:
Сообщение: Re: Failed dependencies: perl(Pg) is needed by postgresql-contrib