"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>>
>> Is this still testing with all data fitting in RAM?
>
> Yes. Having things out of RAM is going to make access even slower, but
> it is going to allow the heap to be in RAM more often.
It would let us measure the actual imp
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Jun 07, 2007 at 06:09:36PM -0400, Alvaro Herrera wrote:
>> Gregory Stark wrote:
>>> When does this bug date to?
>>
>> It was in 8.1. I didn't verify whether it affects on 8.0; I think we
>> separated the shared tables in pgstats in 8.1, with the
On Thu, Jun 07, 2007 at 06:09:36PM -0400, Alvaro Herrera wrote:
> Gregory Stark wrote:
> > When does this bug date to?
>
> It was in 8.1. I didn't verify whether it affects on 8.0; I think we
> separated the shared tables in pgstats in 8.1, with the advent of
> autovacuum, so I assume it doesn't.
On Thu, Jun 07, 2007 at 11:46:17PM +0100, Gregory Stark wrote:
> Does anything use the pgstats data for anything other than presenting feedback
> to users?
>
> Autovacuum uses it to estimate when tables should be vacuumed right? This
> wouldn't have caused autovacuum to go nuts vacuuming these tab
Josh Berkus <[EMAIL PROTECTED]> writes:
> This brings up another point. With the increased number of .conf
> options, the file is getting hard to read again. I'd like to do another
> reorganization, but I don't really want to break people's diff scripts.
Do you have a better organizing princ
Gregory Stark wrote:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >
> > > is it possible it's related to the performance drop immediately
> > > following a vacuum analyze we've been seeing?
> >
> > I don't think so, unless you were counting on pgstats data of shared
Josh Berkus wrote:
All,
This brings up another point. With the increased number of .conf
options, the file is getting hard to read again. I'd like to do another
reorganization, but I don't really want to break people's diff scripts.
Should I worry about that?
As a point of feedback, aut
All,
This brings up another point. With the increased number of .conf
options, the file is getting hard to read again. I'd like to do another
reorganization, but I don't really want to break people's diff scripts.
Should I worry about that?
--Josh
---(end of broa
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Well, it is summarized here:
> >
> > http://momjian.us/expire/TOAST/SUMMARY.html
> >
> > It made non-TOAST access 2x faster, but TOAST 7x slower, and that seemed
> > like a good compromise.
>
> Is this still testing with
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
> > is it possible it's related to the performance drop immediately
> > following a vacuum analyze we've been seeing?
>
> I don't think so, unless you were counting on pgstats data of shared
> tables for something. The optimize
Andrew Hammond escribió:
> That's a good question. I can't see any reason for a naptime longer
> than 60 seconds either.
>
> I think very large naptime settings are a symptom of another issue:
> what's the Right Way to defer vacuums until "off hours"? Is that even
> a desirable thing anymore? I d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/7/07, Matthew T. O'Connor wrote:
Tom Lane wrote:
> "Andrew Hammond" writes:
>> Hmmm... it seems to me that points new users towards not using
>> autovacuum, which doesn't seem like the best idea. I think it'd be
>> better to say that setting t
On Thu, 2007-06-07 at 17:01 +0200, [EMAIL PROTECTED] wrote:
> I've benn biten twice by this one:
> I enabled archiving on both my pgsql servers.
> the archive command was a simple gzip on an nfs mounted dir.
> Now the nfs server crashed.
> Both wal space filled up until postgresql shuts itself dow
Gregory Stark wrote:
>
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > Log Message:
> > ---
> > Avoid losing track of data for shared tables in pgstats. Report by Michael
> > Fuhr, patch from Tom Lane after a messier suggestion by me.
>
> When does this bug date to?
It was in 8.1.
On Thu, 2007-06-07 at 22:20 +0100, Simon Riggs wrote:
> On Sat, 2007-06-02 at 01:07 +0100, Jon Colverson wrote:
> > Simon Riggs wrote:
> > > I've spent some time re-examining the code and I can't see a route for
> > > the discussed problem to occur. All the main code paths do not exhibit
> > > this
Jeff Davis wrote:
On Wed, 2007-06-06 at 22:36 +0100, Simon Riggs wrote:
.) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
is considered to be "later" than any other xid.
So you are bumping FirstNormalTransactionId up by one for this?
You're assuming then that we will
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Log Message:
> ---
> Avoid losing track of data for shared tables in pgstats. Report by Michael
> Fuhr, patch from Tom Lane after a messier suggestion by me.
When does this bug date to? is it possible it's related to the performance
drop im
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
Jeff Davis wrote:
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
similar?
On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote:
> Simon Riggs wrote:
> > On Fri, 2007-03-30 at 16:34 -0400, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> 2. pg_stop_backup() should wait until all archive files are safely
> >>> archived before returning
> >> Not sur
This is really a serious issue with the current design of the database,
one that merely changes instead of going away completely if you throw
more hardware at it. I'm perversely glad to hear this is torturing more
people than just me as it improves the odds the situation will improve.
It to
Simon Riggs wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Added a new GUC operational_mode, which can be set to either
readwrite or readonly. If it is set to readwrite (the default),
postgres behaves as usual. All the following changes are only
in effect if op
On Thu, 7 Jun 2007, Gregory Stark wrote:
You seem to have imagined that letting the checkpoint take longer will slow
down transactions.
And you seem to have imagined that I have so much spare time that I'm just
making stuff up to entertain myself and sow confusion.
I observed some situation
Tom Lane wrote:
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
Hmmm... it seems to me that points new users towards not using
autovacuum, which doesn't seem like the best idea. I think it'd be
better to say that setting the naptime really high is a Bad Idea.
It seems like we should have an upper
"Greg Smith" <[EMAIL PROTECTED]> writes:
> I'm completely biased because of the workloads I've been dealing with
> recently,
> but I consider (2) so much easier to tune for that it's barely worth worrying
> about. If your system is so underloaded that you can let the checkpoints take
> their own
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
> Hmmm... it seems to me that points new users towards not using
> autovacuum, which doesn't seem like the best idea. I think it'd be
> better to say that setting the naptime really high is a Bad Idea.
It seems like we should have an upper limit on the
Clients using pqlib can get some boost by increasing tcp/ip window size.
It might be good to make it a settable parameter.
Anyway, maybe something like this:
/* --
* connectNoDelay -
* Sets the TCP_NODELAY socket option.
* Returns 1 if successful, 0 if not.
* --
*/
s
On 6/7/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Mon, Jun 04, 2007 at 11:04:26AM -0400, Alvaro Herrera wrote:
> The launcher is set up to wake up in autovacuum_naptime seconds at most.
> So if the user configures a ridiculuos time (for example 86400 seconds,
> which I've seen) then the launc
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >Tom Lane wrote:
> >>Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>>But this is misleading (started postmaster with good value, then edited
> >>>postgresql.conf and entered "-2"):
> >>>17903 LOG: received SIGHUP, reloading configuration files
>
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Further investigation shows that what really seems to be happening
> > in 8.3devel is that the statistics for shared tables are reset every
> > 15 seconds when autovacuum is enabled, which it is by default. I
> > don't observe this phe
On Thu, 7 Jun 2007, Heikki Linnakangas wrote:
So there's two extreme ways you can use LDC:
1. Finish the checkpoint as soon as possible, without disturbing other
activity too much
2. Disturb other activity as little as possible, as long as the
checkpoint finishes in a reasonable time.
Are both
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Further investigation shows that what really seems to be happening
> in 8.3devel is that the statistics for shared tables are reset every
> 15 seconds when autovacuum is enabled, which it is by default. I
> don't observe this phenomenon when autovacuum is
On Thu, Jun 07, 2007 at 11:41:56AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The attached patch fixes this.
>
> Wouldn't it be easier to just special-case the shared DB in
> pgstat_vacuum_tabstat?
Thanks; I'll test these patches when I get a chance.
> >> Additionall
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I don't think it's a historical artifact at all: it's a valid reflection
of the fact that we don't know enough about disk layout to do low-level
I/O scheduling. Issuing more fsyncs than necessary will do little
exce
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't think it's a historical artifact at all: it's a valid reflection
>> of the fact that we don't know enough about disk layout to do low-level
>> I/O scheduling. Issuing more fsyncs than necessary will do little
>> except gua
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Thinking about this whole idea a bit more, it occured to me that the
current approach to write all, then fsync all is really a historical
artifact of the fact that we used to use the system-wide sync call
instead of fsyncs to flush
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
But this is misleading (started postmaster with good value, then edited
postgresql.conf and entered "-2"):
17903 LOG: received SIGHUP, reloading configuration files
17903 LOG: -2 is outside the valid range for pa
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > But this is misleading (started postmaster with good value, then edited
> > postgresql.conf and entered "-2"):
>
> > 17903 LOG: received SIGHUP, reloading configuration files
> > 17903 LOG: -2 is outside the valid range for paramet
On Mon, Jun 04, 2007 at 11:04:26AM -0400, Alvaro Herrera wrote:
> The launcher is set up to wake up in autovacuum_naptime seconds at most.
> So if the user configures a ridiculuos time (for example 86400 seconds,
> which I've seen) then the launcher would not detect the postmaster death
Yeah, I've
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 6/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Perhaps a reasonable compromise could work like this: at the first point
>> in a transaction where a temp file is created, choose a random list
>> element, and thereafter advance cyclically for the dura
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that the database hash is cleared of databases that no
> longer exist, and the database list is constructed by scanning
> pg_database. Since no entry exist for the database we use for shared
> tables (InvalidOid), the hash table is droppe
Michael Fuhr wrote:
> Is vacuuming any table supposed to zero the statistics for all
> shared tables? Doesn't that have implications for autovacuum? The
> example below is in 8.2.4 but I'm seeing similar behavior in 8.1.9
> and 8.3devel.
The problem is that the database hash is cleared of databa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, June 07, 2007 14:22:22 +0300 Devrim GÜNDÜZ
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, 2007-06-07 at 13:12 +0200, Peter Eisentraut wrote:
>> make dist[check]
>
> AFAIK "make dist" does not prepare postgres.tar.gz.
right, as peter
Hi all,
I've benn biten twice by this one:
I enabled archiving on both my pgsql servers.
the archive command was a simple gzip on an nfs mounted dir.
Now the nfs server crashed.
Both wal space filled up until postgresql shuts itself down because of no
more space for WAL.
That perfectly normal and
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Thinking about this whole idea a bit more, it occured to me that the
> current approach to write all, then fsync all is really a historical
> artifact of the fact that we used to use the system-wide sync call
> instead of fsyncs to flush the pages
Thinking about this whole idea a bit more, it occured to me that the
current approach to write all, then fsync all is really a historical
artifact of the fact that we used to use the system-wide sync call
instead of fsyncs to flush the pages to disk. That might not be the best
way to do things
Hi,
On Thu, 2007-06-07 at 13:12 +0200, Peter Eisentraut wrote:
> make dist[check]
AFAIK "make dist" does not prepare postgres.tar.gz.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP,
On Thu, Jun 07, 2007 at 01:12:06PM +0200, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is this script in CVS somewhere? I know it's not in the main backend
> > repo.
>
> Most of what these scripts have done in the past has been systematized
> and folded into the "make dist" target in the
Magnus Hagander wrote:
> Is this script in CVS somewhere? I know it's not in the main backend
> repo.
Most of what these scripts have done in the past has been systematized
and folded into the "make dist" target in the mean time, and AFAICT, we
could integrate the documentation preparation as we
On Wed, Jun 06, 2007 at 07:56:25PM -0300, Marc G. Fournier wrote:
> - --On Tuesday, June 05, 2007 10:28:58 +0300 Devrim GÜNDÜZ
> <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi Marc,
> >
> > Is there a written procedure about creating tarballs? I'd like to start
> > working on 8.3 RPMs and I want to know
Florian G. Pflug wrote:
Jeff Davis wrote:
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
similar?
Thats what I currently do
Ühel kenal päeval, K, 2007-06-06 kell 11:03, kirjutas Tom Lane:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > GUC summary and suggested default values
> >
> > checkpoint_write_percent = 50 # % of checkpoint interval to
> > spread out
>
Greg Smith wrote:
On Wed, 6 Jun 2007, Heikki Linnakangas wrote:
The original patch uses bgwriter_all_max_pages to set the minimum
rate. I think we should have a separate variable,
checkpoint_write_min_rate, in KB/s, instead.
Completely agreed. There shouldn't be any coupling with the backgr
52 matches
Mail list logo
