Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 22BF2B5DBFE for ; Thu, 8 Sep 2011 16:33:43 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 03080-06 for ; Thu, 8 Sep 2011 19:33:36 +0000 (UTC) X-Greylist: delayed 06:42:42.668459 by SQLgrey-1.7.6 Received: from mail-gx0-f178.google.com (mail-gx0-f178.google.com [209.85.161.178]) by mail.postgresql.org (Postfix) with ESMTP id A719EB5D80A for ; Thu, 8 Sep 2011 16:33:36 -0300 (ADT) Received: by gxk8 with SMTP id 8so326325gxk.37 for ; Thu, 08 Sep 2011 12:33:36 -0700 (PDT) Received: by 10.91.69.33 with SMTP id w33mr1079953agk.112.1315510416009; Thu, 08 Sep 2011 12:33:36 -0700 (PDT) Received: from AnibalVAIO ([200.85.32.68]) by mx.google.com with ESMTPS id j11sm2049988ang.5.2011.09.08.12.33.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 12:33:33 -0700 (PDT) From: "Anibal David Acosta" To: "'Kevin Grittner'" , Cc: "'Tomas Vondra'" References: <004301cc6e26$015a75e0$040f61a0$@devshock.com> <4E688FFC0200002500040F10@gw.wicourts.gov> <012001cc6e45$fa57f950$ef07ebf0$@devshock.com> <4E68AE600200002500040F47@gw.wicourts.gov> In-Reply-To: <4E68AE600200002500040F47@gw.wicourts.gov> Subject: Re: how delete/insert/update affects select performace? Date: Thu, 8 Sep 2011 15:34:00 -0400 Message-ID: <008001cc6e5e$44737420$cd5a5c60$@devshock.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYrwFqiugYygNYi1ErgOQqHWWRlwF7ZGtRALkg6ZgB5VikY5UKjsfQ Content-Language: es-py X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201109/81 X-Sequence-Number: 44857 >On the other hand, if you have very many rows where enabled is not 'T', and you are generally searching for where enabled = 'T', you might want a partial index (an index with a WHERE clause in its definition). If >enabled only has two states, you will probably get better performance using a boolean column. Maybe 1% or 2% are enabled='F' all others are 'T' Another question Kevin (thanks for your time) When an insert/update occur, the index is "reindexed" how index deals with new or deleted rows. Whay happened with select, it wait that index "reindex" or rebuild or something? Or just select view another "version" of the table? Thanks -----Mensaje original----- De: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov] Enviado el: jueves, 08 de septiembre de 2011 01:01 p.m. Para: Anibal David Acosta; pgsql-performance@postgresql.org CC: 'Tomas Vondra' Asunto: RE: [PERFORM] how delete/insert/update affects select performace? "Anibal David Acosta" wrote: > Tthe reason I add the enabled column to index is because a select > won't need to read the table to get this value That's not true in PostgreSQL, although there is an effort to support that optimization, at least to some degree. In all current versions of PostgreSQL, it will always need to read the heap to determine whether the index entry is pointing at a version of the row which is visible to your transaction. Adding the enabled column to an index will prevent faster HOT updates to that column. > My select is : exists(select * from table where account_id=X and > service_id=Y and enabled='T') On the other hand, if you have very many rows where enabled is not 'T', and you are generally searching for where enabled = 'T', you might want a partial index (an index with a WHERE clause in its definition). If enabled only has two states, you will probably get better performance using a boolean column. -Kevin