X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D08ED9FA5D2 for ; Wed, 31 May 2006 03:30:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 91376-08 for ; Wed, 31 May 2006 03:30:36 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.clickspace.com (router2.clickspace.com [65.110.166.227]) by postgresql.org (Postfix) with ESMTP id E04CB9F9312 for ; Wed, 31 May 2006 03:30:35 -0300 (ADT) Received: from [10.0.1.4] ([68.147.204.179]) (authenticated user brendan@clickspace.com) by mail.clickspace.com (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits)); Wed, 31 May 2006 00:29:59 -0600 In-Reply-To: <20060531062307.GG53487@pervasive.com> References: <961F6F02-4B00-494C-B071-6DF76A305C14@clickspace.com> <21B15664-F4EE-462C-88B4-EEEB2B4A979F@clickspace.com> <874pzanvk6.fsf@stark.xeocode.com> <17733.1148832292@sss.pgh.pa.us> <3C756C36-DC66-4D13-B2CE-99CFCE7BF390@clickspace.com> <87hd39n3c4.fsf@stark.xeocode.com> <20060531062307.GG53487@pervasive.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09F270C9-7DF8-4574-AC70-CD7F9DA2C020@clickspace.com> Cc: Greg Stark , Tom Lane , PostgreSQL Performance Content-Transfer-Encoding: 7bit From: Brendan Duddridge Subject: Re: App very unresponsive while performing simple update Date: Wed, 31 May 2006 00:29:50 -0600 To: "Jim C. Nasby" X-Mailer: Apple Mail (2.750) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/564 X-Sequence-Number: 19351 >> You should realize this will produce a lot of garbage records and >> mean you'll >> have to be running vacuum very frequently. You might consider >> instead of >> updating the main table inserting into a separate clickstream >> table. That >> trades off not getting instantaneous live totals with isolating the >> maintenance headache in a single place. That table will grow large >> but you can >> prune it at your leisure without impacting query performance on >> your main >> tables. We actually already have a table for this purpose. product_click_history > > Actually, you can still get instant results, you just have to hit two > tables to do it. Well, not really for our situation. We use the click_count on product to sort our product listings by popularity. Joining with our product_click_history to get live counts would be very slow. Some categories have many tens of thousands of products. Any joins outside our category_product table tend to be very slow. We'll probably have to write a process to update the click_count from querying our product_click_history table. ____________________________________________________________________ Brendan Duddridge | CTO | 403-277-5591 x24 | brendan@clickspace.com ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On May 31, 2006, at 12:23 AM, Jim C. Nasby wrote: > On Sun, May 28, 2006 at 07:20:59PM -0400, Greg Stark wrote: >> Brendan Duddridge writes: >> >>> We do have foreign keys on other tables that reference the >>> product table. >>> Also, there will be updates going on at the same time as this >>> update. When >>> anyone clicks on a product details link, we issue an update >>> statement to >>> increment the click_count on the product. e.g. update product >>> set click_count >>> = click_count + 1; >> >> You should realize this will produce a lot of garbage records and >> mean you'll >> have to be running vacuum very frequently. You might consider >> instead of >> updating the main table inserting into a separate clickstream >> table. That >> trades off not getting instantaneous live totals with isolating the >> maintenance headache in a single place. That table will grow large >> but you can >> prune it at your leisure without impacting query performance on >> your main >> tables. > > Actually, you can still get instant results, you just have to hit two > tables to do it. > >> More likely you were blocking on some lock. Until that other query >> holding >> that lock tries to commit Postgres won't actually detect a >> deadlock, it'll >> just sit waiting until the lock becomes available. > > Wow, are you sure that's how it works? I would think it would be > able to > detect deadlocks as soon as both processes are waiting on each other's > locks. > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >