Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 7E9CA2E0127 for ; Tue, 29 Apr 2008 08:31:00 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 20819-01-8 for ; Tue, 29 Apr 2008 08:30:57 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by developer.postgresql.org (Postfix) with ESMTP id C6ADA2E015A for ; Tue, 29 Apr 2008 08:25:43 -0300 (ADT) Received: by yw-out-2324.google.com with SMTP id 5so1648679ywb.73 for ; Tue, 29 Apr 2008 04:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=r6buAhKjBEDeUrPvrb0pbwGhy17MMxUYi/Z30M0cJE8=; b=IZdo31AB10IBSZJ/N9FvarGdyz4rf0T/0fxlF01wuuQioqapDkzDWWO09wqD/no0cFTEvEMKTsHb7xBoi3/wC7FZLQHN5sEX39euJZmBxX76nKoh+D0SSckFZe4ueWc2wVNIhJuLFxMaKpGeP4qn4/aOR3rUyLoly0/NT7BC+yA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R2Ch7lQTPv09U1d3QWPV7uSCohZMqdlcRyiRmlA1G68l5GsdMzaiivIiZIe/dznLbEYo4RoKB4qMwJnC7MutNuNQXGLlh8besUfWr1UzJverDHTFmx/bOfA279OEzat7kntiIWsKIO8VziZlL38MYph3Y6S2gQSvLhTh2Brqx40= Received: by 10.150.146.19 with SMTP id t19mr4870576ybd.226.1209468338143; Tue, 29 Apr 2008 04:25:38 -0700 (PDT) Received: by 10.151.84.7 with HTTP; Tue, 29 Apr 2008 04:25:38 -0700 (PDT) Message-ID: <2e78013d0804290425n402f5e94i90bc7206aeefffdc@mail.gmail.com> Date: Tue, 29 Apr 2008 16:55:38 +0530 From: "Pavan Deolasee" To: "Gauri Kanekar" Subject: Re: Replication Syatem Cc: "Greg Smith" , pgsql-performance@postgresql.org In-Reply-To: <7e4ba9550804290405i4c0d3a57x1640239c9995c13@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com> <7e4ba9550804280705q43c51e66l104a5ff9272bbd4d@mail.gmail.com> <20080428162243.GN2970@commandprompt.com> <7e4ba9550804282246p73c62fc6y5e7cb7dda55a6b50@mail.gmail.com> <7e4ba9550804290405i4c0d3a57x1640239c9995c13@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.462 tagged_above=0 required=5 tests=AWL=-1.437, FS_REPLICA=1.179, SARE_SPEC_REPLICA=0.72 X-Spam-Level: X-Archive-Number: 200804/431 X-Sequence-Number: 29924 On Tue, Apr 29, 2008 at 4:35 PM, Gauri Kanekar wrote: > > Do we need to do any special config changes or any other setting for HOT to > work?? No. HOT is enabled by default, on all tables. There is no way and need to disable it. > > Any special guideline to follow to make HOT working?? > You can do couple of things to benefit from HOT. 1. HOT addresses a special, but common case where UPDATE operation does not change any of the index keys. So check if your UPDATE changes any of the index keys. If so, see if you can avoid having index involving that column. Of course, I won't advocate dropping an index if it would drastically impact your frequently run queries. 2. You may leave some free space in the heap (fillfactor less than 100). My recommendation would be to leave space worth of one row or slightly more than that to let first UPDATE be an HOT update. Subsequent UPDATEs in the page may reuse the dead row created by earlier UPDATEs. 3. Avoid any long running transactions. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com