Re: Index behavior question - Mailing list pgsql-novice

From Tom Lane
Subject Re: Index behavior question
Date
Msg-id 5107.1049052298@sss.pgh.pa.us
Whole thread Raw
In response to Index behavior question  (Dmitri Touretsky <dmitri@listsoft.ru>)
List pgsql-novice
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


pgsql-novice by date:

Previous
From: Tony Holmes
Date:
Subject: Modifying WHERE input conditions for a VIEW
Next
From: Tom Lane
Date:
Subject: Re: Modifying WHERE input conditions for a VIEW