pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Brendan Duddridge <brendan@clickspace.com>
To: Jim C. Nasby <jnasby@pervasive.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: App very unresponsive while performing simple update
Date: Wed, 31 May 2006 00:29:50 -0600
Message-ID: <09F270C9-7DF8-4574-AC70-CD7F9DA2C020@clickspace.com> (raw)
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>

>> 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 <brendan@clickspace.com> 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
>





view thread (18+ messages)  latest in thread

Message-ID: <09F270C9-7DF8-4574-AC70-CD7F9DA2C020@clickspace.com>
Permalink:  ../09F270C9-7DF8-4574-AC70-CD7F9DA2C020@clickspace.com/
Also on:    postgresql.org/message-id/09F270C9-7DF8-4574-AC70-CD7F9DA2C020@clickspace.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: brendan@clickspace.com, jnasby@pervasive.com, gsstark@mit.edu, tgl@sss.pgh.pa.us
  Subject: Re: App very unresponsive while performing simple update
  In-Reply-To: <09F270C9-7DF8-4574-AC70-CD7F9DA2C020@clickspace.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox