Re: Schema design question as it pertains to performance - Mailing list pgsql-admin

From Benjamin Krajmalnik
Subject Re: Schema design question as it pertains to performance
Date
Msg-id F4E6A2751A2823418A21D4A160B6898892B89C@fletch.stackdump.local
Whole thread Raw
In response to Re: Schema design question as it pertains to performance  ("Kevin Grittner" <kgrittn@mail.com>)
List pgsql-admin
Thanks, Kevin.
That was my intent - if no column of an index changes in an update then no changes are done on the index.
That helps quite a bit - I will try moving the columns which change continuously to their own index - hopefully this
willtame the overwhelming IO, since the index will now have a single column.  I am seeing too many semwaits or ufs
stateswhen running top, which means we are not quite keeping up.
 
A lot of the load has been offloaded to the read only hot standby - thanks for the pointers on the delays.  I only had
onequery cancelled today (as opposed to many previously), so it is just a matter of fine tuning right now.
 


-----Original Message-----
From: Kevin Grittner [mailto:kgrittn@mail.com] 
Sent: Tuesday, January 22, 2013 2:56 PM
To: Benjamin Krajmalnik; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Schema design question as it pertains to performance

Benjamin Krajmalnik wrote:

> From a performance standpoint, is there a big hit on select 
> performance if a query ends up utilizing more than one index, taking 
> into account that an index has been used already to reduce the data 
> set of potential records, and the secondary index would mostly be used 
> in the ordering of the result set (such as a last updated time)?

That depends on so many variables it is hard to give a simple answer.

> I also assume that if no data has changed in an index, nothing is done 
> when the record is updated as pertains to the particular index - am I 
> correct in this assumption?

No. If the update doesn't affect *any* indexed column, and there is room in the page, it will do a HOT update and can
skipall index updates. If any indexed column is updated, it must expire the old tuple and create a new tuple to
representthe updated version of the row, and this new tuple is not likely to land in the same page as the old tuple; so
itneeds new entries in all the indexes. The old index entries must remain until they can no longer be the visible
versionof the row for any database transaction, so both versions of the row will be on the index for a while.
 

-Kevin

pgsql-admin by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Schema design question as it pertains to performance
Next
From: "Kevin Grittner"
Date:
Subject: Re: Schema design question as it pertains to performance