This question pertains to PG 9.0.4 running on FreeBSD amd64. Was not sure if it should go into the general list or the performance list, so my apologies if I opted for the wrong list. We currently have a db schema which contains many wide indices which usually contain one column which is constantly changing (such as a last update time). It was designed that way because at the time we were unaware that PG could utilize multiple indices in a query. Our database is very heavy un update queries, since the same records get updated many times per minute. As a result, that very wide index is constantly being updated, which I am sure is one of the sources of some heavy disk i/o I am seeing. Until recently, this design was not affecting performance, but as we have more devices sending data, we are seeing a significant hit on the i/o, and data is getting queued by the daemons which insert it creating a backlog of "real time" data. >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)? 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? Our data is already partitioned and triggers send it to the correct partition. Thanks in advance, Benjamin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
