On 3/16/10 6:22 PM, Tom Lane wrote:
> Richard Huxton writes:
>
>
> Um, what if the cycle is being formed from whole cloth? For instance
> T1 inserts an edge A->B while T2 is inserting B->A. There are no
> pre-existing rows to lock, but there will still be a cycle after they
> both commit.
For
On 3/16/10 4:34 PM, Tom Lane wrote:
> The same kind of problem exists for unique and foreign key constraints,
> both of which use low-level locking mechanisms to catch such cases.
> There's no way that I can see to express the "no cycle" constraint as a
> uniqueness constraint unfortunately. You c
I'm using the following table to represent an acyclic directed graph:
CREATE TABLE edge(
id SERIAL PRIMARY KEY,
child INTEGER NOT NULL,
parent INTEGER,
UNIQUE (child, parent)
);
I see there is an example in the online docs for detecting cycles in
recursive
Greg Sabino Mullane wrote:
> A few things spring to mind:
>
> 1) Use a separate table, rather than storing things inside of
> dataset itself. This will reduce the activity on the dataset table.
A separate table just for that one column? Would that really help,
given that I'd have to add the fore
Hi Craig, thanks for your help.
Craig Ringer wrote:
> MVCC bloat from the constant updates to the assoc_count table, maybe?
That's what a coworker suggested might be happening. The fact that a
no-op trigger performs fine but the UPDATE trigger doesn't would seem to
confirm that it's something in
I was looking to speed up a count(*) query, as per the recommendations
on the postgres wiki:
http://wiki.postgresql.org/wiki/Slow_Counting
I decided to use the trigger approach to get an accurate count that
doesn't depend on VACUUM being run recently. I've got it working, but
the addition of the
