BTW, given all the recent discussion about vacuuming and our MVCC,
http://www.pervasive-postgres.com/lp/newsletters/2006/Insights_Postgres_Jan.asp#3
should prove interesting. :)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com
Jim C. Nasby wrote:
BTW, given all the recent discussion about vacuuming and our MVCC,
http://www.pervasive-postgres.com/lp/newsletters/2006/Insights_Postgres_Jan.asp#3
should prove interesting. :)
Please explain... what is the .asp extension. I have yet to see it
reliable in production ;)
On Fri, Jan 20, 2006 at 09:31:14AM -0800, Joshua D. Drake wrote:
Jim C. Nasby wrote:
BTW, given all the recent discussion about vacuuming and our MVCC,
http://www.pervasive-postgres.com/lp/newsletters/2006/Insights_Postgres_Jan.asp#3
should prove interesting. :)
Please explain... what is
I lay no claim to our infrastructure. :)
Can I quote the: Pervasive Senior Engineering Consultant on that?
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
On Fri, Jan 20, 2006 at 09:37:50AM -0800, Joshua D. Drake wrote:
I lay no claim to our infrastructure. :)
Can I quote the: Pervasive Senior Engineering Consultant on that?
Sure... I've never been asked to consult on our stuff, and in any case,
I don't do web front-ends (one of the nice
Sure... I've never been asked to consult on our stuff, and in any case,
I don't do web front-ends (one of the nice things about working with a
team of other consultants). AFAIK IIS will happily talk to PostgreSQL
(though maybe I'm wrong there...)
iis (yeah, asp in a successfull productive
On Fri, Jan 20, 2006 at 06:46:45PM +0100, [EMAIL PROTECTED] wrote:
Sure... I've never been asked to consult on our stuff, and in any case,
I don't do web front-ends (one of the nice things about working with a
team of other consultants). AFAIK IIS will happily talk to PostgreSQL
(though maybe
Jim C. Nasby wrote:
I think it's a good idea, but you should take a look at the recently
added functionality that allows you to investigate the contests of the
FSM via a user function (this is either in 8.1 or in HEAD; I can't
remember which).
AFAICS it is still in the patch queue for 8.2.
Verified. I am working toward getting all those patches applied.
---
Mark Kirkwood wrote:
Jim C. Nasby wrote:
I think it's a good idea, but you should take a look at the recently
added functionality that allows
There's a number of sites that have lots of info on postgresql.conf
tuning. Google for 'postgresql.conf tuning' or 'annotated
postgresql.conf'.
I know some of these sites, but who should I know if the information on
those pages is correct? The information on those pages should be
published as
Even a database-wide vacuum does not take locks on more than one table.
The table locks are acquired and released one by one, as the operation
proceeds.
Has that changed recently? I have always seen vacuumdb or SQL
VACUUM (without table specifications) running as one long
Mindaugas wrote:
Even a database-wide vacuum does not take locks on more than one table.
The table locks are acquired and released one by one, as the operation
proceeds.
Has that changed recently? I have always seen vacuumdb or SQL
VACUUM (without table specifications) running
[EMAIL PROTECTED] (Mindaugas) writes:
Even a database-wide vacuum does not take locks on more than one
table. The table locks are acquired and released one by one, as
the operation proceeds.
Has that changed recently? I have always seen vacuumdb or SQL
VACUUM (without table
On Wednesday 18 January 2006 08:54 am, Chris Browne wrote:
To the contrary, there is a whole section on what functionality to
*ADD* to VACUUM.
Near but not quite off the topic of VACUUM and new features...
I've been thinking about parsing the vacuum output and storing it in
Postgresql. All
On Wed, Jan 18, 2006 at 03:09:42PM +0100, Michael Riess wrote:
There's a number of sites that have lots of info on postgresql.conf
tuning. Google for 'postgresql.conf tuning' or 'annotated
postgresql.conf'.
I know some of these sites, but who should I know if the information on
those pages
On Wed, Jan 18, 2006 at 11:15:51AM -0800, Michael Crozier wrote:
I've been thinking about parsing the vacuum output and storing it in
Postgresql. All the tuple, page, cpu time, etc... information would be
inserted into a reasonably flat set of tables.
snip
Assuming this isn't a
[EMAIL PROTECTED] (Michael Crozier) writes:
On Wednesday 18 January 2006 08:54 am, Chris Browne wrote:
To the contrary, there is a whole section on what functionality to
*ADD* to VACUUM.
Near but not quite off the topic of VACUUM and new features...
I've been thinking about parsing the
On Wednesday 18 January 2006 14:52 pm, Jim C. Nasby wrote:
I think it's a good idea, but you should take a look at the recently
added functionality that allows you to investigate the contests of the
FSM via a user function (this is either in 8.1 or in HEAD; I can't
remember which).
I will
We had someone working on that for a while; I don't think it got to
the point of being something ready to unleash on the world.
Interesting. I will dig around the mailing list archives too see how they
went about it... for my own curiosity if nothing else. If you happen to
know offhand,
On Wed, Jan 18, 2006 at 03:36:04PM -0800, Michael Crozier wrote:
On Wednesday 18 January 2006 14:52 pm, Jim C. Nasby wrote:
I think it's a good idea, but you should take a look at the recently
added functionality that allows you to investigate the contests of the
FSM via a user function
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
know that the necessity of doing full vacuums can be reduced by
increasing the FSM, but in my opinion that is the wrong decision for
many applications. My application does not continuously
insert/update/delete tuples
So my question is: What's the use of an autovacuum daemon if I still
have to use a cron job to do full vacuums? wouldn't it just be a minor
job to enhance autovacuum to be able to perform full vacuums, if one
really wants it to do that - even if some developers think that it's the
wrong
Hi,
did you read my post? In the first part I explained why I don't want to
increase the FSM that much.
Mike
So my question is: What's the use of an autovacuum daemon if I still
have to use a cron job to do full vacuums? wouldn't it just be a minor
job to enhance autovacuum to be able to
You should never have to do full vacuums...
I would rather say, You should never have to do full vacuums by any
periodic means. It may be done on a adhoc basis, when you have figured
out that your table is never going to grow that big again.
On 1/17/06, Christopher Kings-Lynne [EMAIL PROTECTED]
On Tue, Jan 17, 2006 at 11:33:02AM +0100, Michael Riess wrote:
did you read my post? In the first part I explained why I don't want to
increase the FSM that much.
Since you didn't quantify it, that wasn't much of a data point. (IOW,
you'd generally have to be seriously resource constrained
Michael Riess wrote:
hi,
I'm curious as to why autovacuum is not designed to do full vacuum.
Because a VACUUM FULL is too invasive. Lazy vacuum is so light on the
system w.r.t. locks that it's generally not a problem to start one at
any time. On the contrary, vacuum full could be a disaster
I'm curious as to why autovacuum is not designed to do full vacuum.
Because that's terribly invasive due to the locks it takes out.
Lazy vacuum may chew some I/O, but it does *not* block your
application for the duration.
VACUUM FULL blocks the application. That is NOT something that anyone
VACUUM FULL blocks the application. That is NOT something that anyone
wants to throw into the activity mix randomly.
There must be a way to implement a daemon which frees up space of a
relation without blocking it too long. It could abort after a certain
number of blocks have been freed
Well,
I think that the documentation is not exactly easy to understand. I
always wondered why there are no examples for common postgresql
configurations. All I know is that the default configuration seems to be
too low for production use. And while running postgres I get no hints as
to which
On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote:
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
Because nothing that runs automatically should ever take an exclusive
lock on the entire database, which is what VACUUM FULL does.
activity. Increasing
Hi,
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
Because nothing that runs automatically should ever take an exclusive
lock on the entire database, which is what VACUUM FULL does.
I thought that vacuum full only locks the table which it currently
operates on?
On Tue, Jan 17, 2006 at 03:50:38PM +0100, Michael Riess wrote:
about the FSM: You say that increasing the FSM is fairly cheap - how
should I know that?
Why would you assume otherwise, to the point of not considering changing
the setting?
The documentation explains how much memory is used
On Tue, Jan 17, 2006 at 03:50:38PM +0100, Michael Riess wrote:
always wondered why there are no examples for common postgresql
configurations.
You mean like this one? (for 8.0):
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
All I know is that the default configuration
On Tue, Jan 17, 2006 at 09:09:02AM -0500, Matthew T. O'Connor wrote:
vacuum. As long as that percentage is small enough, the effect on
performance is negligible. Have you measured to see if things are truly
Actually, as long as the percentage is small enough and the pages are
really empty,
On 1/17/06, Michael Riess [EMAIL PROTECTED] wrote:
about the FSM: You say that increasing the FSM is fairly cheap - howshould I know that?comment from original postgresql.conf file seems pretty obvious:#max_fsm_pages = 2 # min max_fsm_relations*16, 6 bytes each
#max_fsm_relations = 1000 # min
Michael Riess [EMAIL PROTECTED] writes:
I'm curious as to why autovacuum is not designed to do full vacuum.
Locking considerations. VACUUM FULL takes an exclusive lock, which
blocks any foreground transactions that want to touch the table ---
so it's really not the sort of thing you want being
On Tue, Jan 17, 2006 at 04:04:41PM +0100, Michael Riess wrote:
I thought that vacuum full only locks the table which it currently
operates on? I'm pretty sure that once a table has been vacuumed, it can
be accessed without any restrictions while the vacuum process works on
the next table.
Michael Riess [EMAIL PROTECTED] writes:
But actually I never understood why the database system slows down at
all when there is much unused space in the files.
Perhaps some of your common queries are doing sequential scans? Those
would visit the empty pages as well as the full ones.
On Tue, 2006-01-17 at 09:08, Andrew Sullivan wrote:
On Tue, Jan 17, 2006 at 03:50:38PM +0100, Michael Riess wrote:
always wondered why there are no examples for common postgresql
configurations.
You mean like this one? (for 8.0):
[EMAIL PROTECTED] (Andrew Sullivan) writes:
On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote:
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
Because nothing that runs automatically should ever take an exclusive
lock on the entire database, which is
On Tue, Jan 17, 2006 at 09:59:25AM -0600, Scott Marlowe wrote:
I have to admit, looking at the documentation, that we really don't
explain this all that well in the administration section, and I can see
how easily led astray beginners are.
I understand what you mean, but I suppose my reaction
Hi, Michael,
Michael Riess wrote:
But actually I never understood why the database system slows down at
all when there is much unused space in the files. Are the unused pages
cached by the system, or is there another reason for the impact on the
performance?
No, they are not cached as such,
Chris Browne wrote:
[EMAIL PROTECTED] (Andrew Sullivan) writes:
On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote:
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
Because nothing that runs automatically should ever take an exclusive
lock on
On Tue, 2006-01-17 at 11:16, Andrew Sullivan wrote:
On Tue, Jan 17, 2006 at 09:59:25AM -0600, Scott Marlowe wrote:
I have to admit, looking at the documentation, that we really don't
explain this all that well in the administration section, and I can see
how easily led astray beginners are.
On Tue, Jan 17, 2006 at 11:43:14AM -0500, Chris Browne wrote:
[EMAIL PROTECTED] (Andrew Sullivan) writes:
Because nothing that runs automatically should ever take an exclusive
lock on the entire database,
That's a bit more than what autovacuum would probably do...
Or even VACUUM FULL, as
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Chris Browne wrote:
[EMAIL PROTECTED] (Andrew Sullivan) writes:
On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote:
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
Because nothing that runs
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Even a database-wide vacuum does not take locks on more than one table.
The table locks are acquired and released one by one, as the operation
proceeds.
Has that changed recently? I have always seen vacuumdb
On Tue, Jan 17, 2006 at 03:50:38PM +0100, Michael Riess wrote:
Well,
I think that the documentation is not exactly easy to understand. I
always wondered why there are no examples for common postgresql
configurations. All I know is that the default configuration seems to be
too low for
48 matches
Mail list logo
