From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Marc Morin <marc(at)sandvine(dot)com> |
Cc: | Markus Schaber <schabi(at)logix-tt(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: partitioning and locking problems |
Date: | 2006-02-07 22:09:02 |
Message-ID: | 1139350142.1258.174.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2006-02-02 at 11:27 -0500, Marc Morin wrote:
> > > 1- long running report is running on view
> > > 2- continuous inserters into view into a table via a rule
> > > 3- truncate or rule change occurs, taking an exclusive lock.
> > > Must wait for #1 to finish.
> > > 4- new reports and inserters must now wait for #3.
> > > 5- now everyone is waiting for a single query in #1. Results
> > > in loss of insert data granularity (important for our application).
> Using a separate lock table is what we've decided to do in this
> particular case to serialize #1 and #3. Inserters don't take this lock
> and as such will not be stalled.
Would it not be simpler to have the Inserters change from one table to
another either upon command, on a fixed timing cycle or even better
based upon one of the inserted values (Logdate?) (or all 3?). (Requires
changes in the application layer: 3GL or db functions).
The truncates can wait until the data has stopped being used.
I'd be disinclined to using the locking system as a scheduling tool.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2006-02-07 22:22:22 | Re: partitioning and locking problems |
Previous Message | Michael Stone | 2006-02-07 14:20:08 | Re: Default autovacuum settings too conservative |