-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> A separate table just for that one column? Would that really help,
> given that I'd have to add the foreign key dataset_id to the related
> table? How does splitting activity across dataset and, say,
> dataset_counts help things?
Well, it r
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I was looking to speed up a count(*) query
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.
2) Do you really need bigint for the c
On 04/02/2009 03:32 PM, Tom Lane wrote:
Tony Cebzanov writes:
What I want to do is update the assoc_count field in the dataset table
to reflect the count of related records in the assoc field. To do so, I
added the following trigger:
CREATE OR REPLACE FUNCTIO
Tony Cebzanov writes:
> What I want to do is update the assoc_count field in the dataset table
> to reflect the count of related records in the assoc field. To do so, I
> added the following trigger:
> CREATE OR REPLACE FUNCTION update_assoc_count_insert()
> RETURNS TRIGGER AS
> '
> BEGIN
>
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
Tony Cebzanov wrote:
> The throughput of the first batch of 1,000 is diminished, but still
> tolerable, but after 10,000 inserts, it's gotten much worse. This
> pattern continues, to the point where performance is unacceptable after
> 20k or 30k inserts.
>
> To rule out the performance of the tr
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
