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
On Wednesday 31 May 2006 02:29, Brendan Duddridge wrote:
We'll probably have to write a process to update the click_count from
querying our product_click_history table.
How about an insert trigger on product_click_history which updates click_count
every say 1 transactions or so?
jan
--
On Wed, May 31, 2006 at 01:23:07 -0500,
Jim C. Nasby [EMAIL PROTECTED] wrote:
On Sun, May 28, 2006 at 07:20:59PM -0400, Greg Stark wrote:
Brendan Duddridge [EMAIL PROTECTED] writes:
More likely you were blocking on some lock. Until that other query holding
that lock tries to commit
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, May 28, 2006 at 07:20:59PM -0400, Greg Stark wrote:
Brendan Duddridge [EMAIL PROTECTED] 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
Hi Jan,
That sounds like a great idea! How would you control the update to
occur only every 10,000 transactions?
Is there a trigger setting for that somewhere?
Thanks,
Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL
On Wednesday 31 May 2006 13:34, Brendan Duddridge wrote:
Hi Jan,
That sounds like a great idea! How would you control the update to
occur only every 10,000 transactions?
Is there a trigger setting for that somewhere?
I was thinking something like
IF count(*) % 1 = 0 then
... do stuff
On Wed, May 31, 2006 at 11:24:05AM -0400, Greg Stark wrote:
stark= begin;
BEGIN
Jim C. Nasby [EMAIL PROTECTED] writes:
I tried duplicating this but couldn't. What's the data in the tables?
Sorry, I had intended to include the definition and data:
stark= create table t1 (a integer primary key, b integer);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
Hi,Is Postgres supposed to be able to handle concurrent requests while doing large updates?This morning I was executing the following simple update statement that would affect 220,000 rows in my product table:update product set is_hungry = 'true' where date_modified current_date - 10;But the
Further to my issue, the update never did finish. I received the following message in psql:ssprod=# update product set is_hungry = 'true' where date_modified current_date - 10;ERROR: deadlock detectedDETAIL: Process 18778 waits for ShareLock on transaction 711698780; blocked by process
Brendan Duddridge [EMAIL PROTECTED] writes:
Further to my issue, the update never did finish. I received the following
message in psql:
ssprod=# update product set is_hungry = 'true' where date_modified
current_date - 10;
ERROR: deadlock detected
DETAIL: Process 18778 waits for
Greg Stark [EMAIL PROTECTED] writes:
What queries are those two processes executing? And what foreign keys do you
have on the product table or elsewhere referring to the product table? And
what indexes do you have on those columns?
And what PG version is this? Alvaro fixed the
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
What queries are those two processes executing? And what foreign keys do you
have on the product table or elsewhere referring to the product table? And
what indexes do you have on those columns?
And what PG version
Hi,
Thanks for your replies.
We are using PostgreSQL 8.1.3 on OS X Server.
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
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
And what PG version is this? Alvaro fixed the
foreign-keys-take-exclusive-locks problem in 8.1 ...
Except I don't think this is taking an exclusive lock at all. The original
post had the deadlock detection fire on a
Brendan Duddridge [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Except I don't think this is taking an exclusive lock at all. The original
post had the deadlock detection fire on a SharedLock.
Yeah, but it was a ShareLock on a transaction ID, which is the trace
of something
17 matches
Mail list logo
