Added to TODO:
* Reduce file system activity overhead of statistics file pgstat.stat
http://archives.postgresql.org/pgsql-general/2007-12/msg00106.php
---
Erik Jones wrote:
> Hi, I'm currently doctoring a situation wher
On Dec 5, 2007, at 7:50 AM, Robert Treat wrote:
On Wednesday 05 December 2007 07:22, Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 03 December 2007 20:22, Erik Jones wrote:
Interesting. If this is anything you'd like to look into I can
provide whatever diagnostic output you need (iosta
On Dec 5, 2007, at 7:50 AM, Robert Treat wrote:
On Wednesday 05 December 2007 07:22, Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 03 December 2007 20:22, Erik Jones wrote:
Interesting. If this is anything you'd like to look into I can
provide whatever diagnostic output you need (iost
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> But then I thought, why do we need it to be a file
> at all? Why not use a mmap'ed memory area or something like that, and
> only write it to a file on postmaster shutdown?
Yeah, we definitely need some other technology for this. The difficulty
is in
On Wednesday 05 December 2007 07:22, Alvaro Herrera wrote:
> Robert Treat wrote:
> > On Monday 03 December 2007 20:22, Erik Jones wrote:
> > > Interesting. If this is anything you'd like to look into I can
> > > provide whatever diagnostic output you need (iostat, vmstat, dtrace
> > > script outpu
Robert Treat wrote:
> On Monday 03 December 2007 20:22, Erik Jones wrote:
> > Interesting. If this is anything you'd like to look into I can
> > provide whatever diagnostic output you need (iostat, vmstat, dtrace
> > script outputs, etc...) but I do have to reiterate that we are an
> > extreme co
On Monday 03 December 2007 20:22, Erik Jones wrote:
> On Dec 3, 2007, at 6:10 PM, Tom Lane wrote:
> > Erik Jones <[EMAIL PROTECTED]> writes:
> >> 8.2.5 on Solaris 10. Before we upgraded to 8.2.4 it was doing about
> >> 65 Mbs/sec. Interestingly, a while back we were running with the
> >> data dir
Erik Jones <[EMAIL PROTECTED]> writes:
> For now, is renaming the
> #define'd paths for the stats file and temp file sufficient for
> moving them?
I would think so, but haven't tried it. There definitely shouldn't be
anything outside pgstat.c that's touching them.
reg
On Dec 3, 2007, at 6:10 PM, Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
8.2.5 on Solaris 10. Before we upgraded to 8.2.4 it was doing about
65 Mbs/sec. Interestingly, a while back we were running with the
data directory mounted with forcedirectio and saw none of this, I'm
guessing
Erik Jones <[EMAIL PROTECTED]> writes:
> 8.2.5 on Solaris 10. Before we upgraded to 8.2.4 it was doing about
> 65 Mbs/sec. Interestingly, a while back we were running with the
> data directory mounted with forcedirectio and saw none of this, I'm
> guessing that fsync calls would have someth
On Dec 3, 2007, at 4:16 PM, Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
Hi, I'm currently doctoring a situation wherein we've got table
inheritance scheme that over the years that has ballooned like only
in your nightmares (think well over 100K tables + indexes on those).
The obvious
Erik Jones <[EMAIL PROTECTED]> writes:
> Hi, I'm currently doctoring a situation wherein we've got table
> inheritance scheme that over the years that has ballooned like only
> in your nightmares (think well over 100K tables + indexes on those).
> The obvious solution is to re-design the sch
Hi, I'm currently doctoring a situation wherein we've got table
inheritance scheme that over the years that has ballooned like only
in your nightmares (think well over 100K tables + indexes on those).
The obvious solution is to re-design the schema with a better
partitioning scheme in mind
13 matches
Mail list logo
