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
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
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
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
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
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
