Обсуждение: Index behavior question

Поиск
Список
Период
Сортировка

Index behavior question

От
Dmitri Touretsky
Дата:
Good time of the day!

It might be that this question is for hackers group, but 'cause I'm
novice I've decided to ask here first :))

In the docs it's written that index changes every time update is done
to the table. But if I update the field which is not indexed - will
postgres spend much time on changing indexes?

The idea is that I have a large table with many indexes defined. The
table has much more selects, than updates or inserts. But in this
table there are few fields which do not require indexing, but needs to
be updates relatively often. Yet I want to keep selects as fast as
possible. And now I'm thinking if it worth to create a separate table
with foreign key defined for those fields...

--
Best regards,
 Dmitri Touretsky ( dmitri@listsoft.ru )

New SOFT daily (RUS):  http://www.listsoft.ru/
               (ENG):  http://www.listsoft.com/
---
One man's error is another man's data.


Re: Index behavior question

От
Tom Lane
Дата:
Dmitri Touretsky <dmitri@listsoft.ru> writes:
> In the docs it's written that index changes every time update is done
> to the table. But if I update the field which is not indexed - will
> postgres spend much time on changing indexes?

It doesn't matter which columns you update.  Any UPDATE writes a new
version of the row, which requires all its own index entries.  The old
row version and its index entries stay around until VACUUM reclaims
them.  You can read more about this in the "concurrency control" chapter
of the manual.

> The idea is that I have a large table with many indexes defined. The
> table has much more selects, than updates or inserts. But in this
> table there are few fields which do not require indexing, but needs to
> be updates relatively often. Yet I want to keep selects as fast as
> possible. And now I'm thinking if it worth to create a separate table
> with foreign key defined for those fields...

I think this would only win if most of your selects didn't need to
access the columns you'd moved out to a separate table.  Otherwise the
cost of joining will slow down the selects more than you want.

            regards, tom lane