Skip site navigation (1) Skip section navigation (2)

Re: Scaling up deferred unique checks and the after trigger queue

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Scaling up deferred unique checks and the after trigger queue
Date: 2009-10-25 15:56:16
Message-ID: 1256486176.8450.4868.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 2009-10-19 at 17:48 +0100, Dean Rasheed wrote:

> This is a WIP patch to replace the after-trigger queues with TID bitmaps
> to prevent them from using excessive amounts of memory. Each round of
> trigger executions is a modified bitmap heap scan.

This is an interesting patch. The justification is fine, the idea is
good, though I'd like to see more analysis of the technique, what other
options exist and some thought about when we should use the technique.

We have a bitmap for each UPDATE statement, I think, but there's no docs
or readme. Why just UPDATE? Is the cost of starting up the bitmap higher
than the existing mechanism? Do we need to look at starting with an
existing mechanism and then switching over to new mechanism? Is the TID
bitmap always a win for large numbers of rows?

The technique relies on these assumptions
* Trigger functions are idempotent
* Trigger execution order is not important (in terms of rows)
* Multiple trigger execution order is not important

All of those seem false in the general case. What will you do?

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-10-25 16:05:54
Subject: per-tablespace random_page_cost/seq_page_cost
Previous:From: Andreas SchmidtDate: 2009-10-25 15:34:26
Subject: pg_standby doesnt't work

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group