> Jim C. Nasby wrote:
>> On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote:
>>
>>>Hi, Jim,
>>>
>>>Jim C. Nasby wrote:
>>>
>>>
What we really need is a replacement for vacuum_delay that takes
PostgreSQL generated IO activity into account...
>>>
>>>There are also other ideas whic
Jim C. Nasby wrote:
On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote:
Hi, Jim,
Jim C. Nasby wrote:
What we really need is a replacement for vacuum_delay that takes
PostgreSQL generated IO activity into account...
There are also other ideas which can make vacuum less painfull
On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote:
> Hi, Jim,
>
> Jim C. Nasby wrote:
>
> > What we really need is a replacement for vacuum_delay that takes
> > PostgreSQL generated IO activity into account...
>
> There are also other ideas which can make vacuum less painfull:
>
>
On Tue, Feb 07, 2006 at 10:09:02PM +, Simon Riggs wrote:
> 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 occur
All good ideas, unfortunately, we can't change the inserting applicatin
code easily.
> -Original Message-
> From: Simon Riggs [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 07, 2006 5:09 PM
> To: Marc Morin
> Cc: Markus Schaber; pgsql-performance@postgresql.org
> Subject: Re: [PERFO
At 05:09 PM 2/7/2006, Simon Riggs wrote:
I'd be disinclined to using the locking system as a scheduling tool.
I Agree with Simon. Using the locking system for scheduling feels
like a form of Programming by Side Effect.
Ron
---(end of broadcast)---
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
On Mon, Feb 06, 2006 at 11:05:45PM -0600, Jim C. Nasby wrote:
I don't really see the logic behind that. Problems caused by inadequate
vacuuming seem to be much more prevalent than problems caused by vacuum
impacting the system.
Agreed. If your tables are large enough that a vacuum matters, you
Hi, Jim,
Jim C. Nasby wrote:
> What we really need is a replacement for vacuum_delay that takes
> PostgreSQL generated IO activity into account...
There are also other ideas which can make vacuum less painfull:
- Use a "delete"-map (like the free space map) so vacuum can quickly
find the pages
