Hi folks!
On Tue, Jun 14, 2005 at 11:39:06AM -0600, Jonah H. Harris wrote:
On second thought, we need to have a GUC for this, whether I want it or
not. It needs to be optional to the log, yes? So it would be:
log_tablespace_full = %
with the default being 0 (don't log).
On third thought,
On Wed, 15 Jun 2005, Bruce Momjian wrote:
K, that's what confused me as I got the impression it was ok to require
LGPL libraries but not GPL.
I think the answer isn't clear on that one.
If that is not clear then what is the difference between a LGPL lib and a
GPL one? To copy code from
On T, 2005-06-14 at 21:23 -0400, Bruce Momjian wrote:
One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
think it has to be done in four stages:
o move it into the backend and have it start/stop automatically
o move the autovacuum configuration parameters
On K, 2005-06-15 at 13:41 +0800, Qingqing Zhou wrote:
Neil Conway [EMAIL PROTECTED] writes
Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
stats collector?
I don't understand. Currently the basic logic of pg_autovacuum is to use the
pg_stat_all_tables numbers
Qingqing Zhou [EMAIL PROTECTED] writes
The start/stop routine is quite like Bgwriter.
I just realized that the non-standard backend can't execute any SQL command.
If so, how would the background pg_autovacuum do vacuum? It could be
forked more like a standard backend, but this is obviously
Hannu Krosing wrote:
On K, 2005-06-15 at 13:41 +0800, Qingqing Zhou wrote:
Neil Conway [EMAIL PROTECTED] writes
Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
stats collector?
I don't understand. Currently the basic logic of pg_autovacuum is to use the
Dennis Bjorklund wrote:
On Wed, 15 Jun 2005, Bruce Momjian wrote:
K, that's what confused me as I got the impression it was ok to require
LGPL libraries but not GPL.
I think the answer isn't clear on that one.
If that is not clear then what is the difference between a LGPL lib and
LGPL libs are used all over by all kinds of closed sorce applications and
that's the whole idea of making things (like glib) into LGPL instead of
GPL. For example Acrobat Reader 7 for unix uses GTK+ and it is LGPL.
Acrobat Reader surely do require GTK+.
Maybe LGPL is OK, but I think we
Bruce Momjian wrote:
Maybe LGPL is OK, but I think we will try to avoid a dependency on LGPL
code if we can help it.
License issues aside, should we not be trying to avoid adding
dependencies on third party libraries, especially those that are not
standard on most operating systems?
Andrew Dunstan wrote:
Bruce Momjian wrote:
Maybe LGPL is OK, but I think we will try to avoid a dependency on LGPL
code if we can help it.
License issues aside, should we not be trying to avoid adding
dependencies on third party libraries, especially those that are not
On Wed, Jun 15, 2005 at 11:23:20AM +0800, Qingqing Zhou wrote:
Who would like to get started on this? It seems pretty straight-forward.
I'd like to give it a try.
I'm on it. I have Matthew's patch, updated to current sources, and I'm
working on cleaning it up to address all known
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good one.
---
Qingqing Zhou wrote:
Qingqing Zhou [EMAIL PROTECTED] writes
The
Alvaro Herrera wrote:
On Wed, Jun 15, 2005 at 11:23:20AM +0800, Qingqing Zhou wrote:
Who would like to get started on this? It seems pretty straight-forward.
I'd like to give it a try.
I'm on it. I have Matthew's patch, updated to current sources, and I'm
working on cleaning it up
John,
What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html) library for
some functionality in pg?
Additionally,. I came across this fine library
(http://home.gna.org/uri/uri.en.html) which I'd like to use as a base
for a new URI type,
Qingqing,
add a parameter to let user pass in the configuration parameters:
* autovacuum_command = -s 100 -S 1 ...
um, can we have these as separate GUCs and not lumped together as a string?
i.e.:
autovacuum_frequency = 60 #seconds, 0 = disable
autovacuum_vacuum_threshold = 200
Without more information to provide at this time, does the following seem
unusual?
INFO: free space map: 252 relations, 411494 pages stored; 738640 total pages
needed
DETAIL: Allocated FSM size: 2000 relations + 40 pages = 2463 kB shared
memory.
I know there are alot of factors
Josh,
Both of these would be fine as add-ins to be distributed *separately*
through
pgFoundry or even the mirrors if they prove popular.
Bundling them in unified distribution binaries with PostgreSQL would
be a
significant problem.
You see this in other projects all the time:
Teodor Sigaev wrote:
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog records, so that the cleanup step
has everything it needs. Or resort to brute-force search
Marc,
Without more information to provide at this time, does the following
seem unusual?
INFO: free space map: 252 relations, 411494 pages stored; 738640 total
pages needed DETAIL: Allocated FSM size: 2000 relations + 40 pages
= 2463 kB shared memory.
Looks like you haven't run
INFO: analyzing pg_catalog.pg_depend
INFO: pg_depend: 27 pages, 3866 rows sampled, 3866 estimated total
rows
INFO: free space map: 423 relations, 88475 pages stored; 431200 total
pages needed
DETAIL: Allocated FSM size: 4000 relations + 8 pages = 705 kB
shared memory.
This, on a database
On Wed, 15 Jun 2005, Stefan Kaltenbrunner wrote:
Teodor Sigaev wrote:
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog records, so that the cleanup step
has everything
Bruce Momjian wrote:
Hannu Krosing wrote:
On K, 2005-06-15 at 13:41 +0800, Qingqing Zhou wrote:
Neil Conway [EMAIL PROTECTED] writes
Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
stats collector?
Yes, those are step five. The TODO list has:
Bruce Momjian wrote:
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good one.
It is a big question, at least it's the main stumbling block I had, and
it's the one that kept my work from being integrated
Josh Berkus wrote:
Qingqing,
add a parameter to let user pass in the configuration parameters:
* autovacuum_command = -s 100 -S 1 ...
um, can we have these as separate GUCs and not lumped together as a string?
i.e.:
autovacuum_frequency = 60 #seconds, 0 = disable
Hannu Krosing wrote:
Can autovacuum yet be configured _not_ to run vacuum during some hours
or above some load ?
That is certainly a goal, hopefully it will get done for 8.1.The
actual design I had in mind (based on prior discussion on hackers) is to
allow a maintenance window that
Matthew T. O'Connor wrote:
I don't think the current implementation if VACUUM can support that. I
believe that all the work will get rolled back if gets canceled.
Perhaps a decent solution would be to have autovacuum increase the
vacuum delay settings dynamically based on system load
On Fri, 2005-06-10 at 02:10 -0400, Tom Lane wrote:
What I see in the profile is
% cumulative self self total
time seconds secondscalls s/call s/call name
42.04 15.5815.58 9214 0.00 0.00 list_nth_cell
20.29 23.10
On Wed, 15 Jun 2005, Bruce Momjian wrote:
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good one.
I'm wondering if effort is being misdirected here. I remember when Mark
Wong at OSDL was running pg_autovacuum
um, can we have these as separate GUCs and not lumped together as a
string? i.e.:
autovacuum_frequency = 60 #seconds, 0 = disable
autovacuum_vacuum_threshold = 200
autovacuum_vacuum_multiple = 0.5
autovacuum_analyze_threshold = 100
autovacuum_analyze_multiple = 0.4
AV should be disabled by
I totally agree. I think we know pg_autovacuum is just a short-term
solution. What we need is for someone to take the lead in this.
The TODO list has the ideas documented. There is no reason the
background writer could not load the FSM directly with free pages.
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
The only thing that I'd need to modify is add the datdba field to
pg_database, so we can figure out an appropiate user for vacuuming each
Where are we on 2-phase commit? Alvaro posted a patch. Is he
completing it for 8.1? Is Tom?
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can
On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
On Wed, 15 Jun 2005, Bruce Momjian wrote:
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good one.
I'm wondering if effort is being
Bruce Momjian pgman@candle.pha.pa.us writes:
Where are we on 2-phase commit? Alvaro posted a patch. Is he
completing it for 8.1? Is Tom?
Hacking on it now ...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you
On Thu, 16 Jun 2005 12:54 pm, Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
On Wed, 15 Jun 2005, Bruce Momjian wrote:
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is
Gavin, People,
I'm wondering if effort is being misdirected here. I remember when Mark
Wong at OSDL was running pg_autovacuum during a dbt run, he was seeing
significant performance loss -- I think on the order of 30% to 40% (I will
try and dig up a link to the results).
It wasn't quite that
Alvaro Herrera wrote:
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
The only thing that I'd need to modify is add the datdba field to
pg_database, so we can figure out an appropiate
On Wed, 15 Jun 2005, Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
On Wed, 15 Jun 2005, Bruce Momjian wrote:
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good
The big leap will be to get it in the backend, which will as Chris KL suggested
stop people shooting themselves in the foot.
I'm not sure what strict rules are imposed by Feature freeze, but there may be
time for others to make some improvements before 8.1.
We have also looked at this for at
On Wed, Jun 15, 2005 at 11:42:17PM -0400, Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
The only thing that I'd need to modify is
Alvaro,
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options would be to have one per
database, and one per tablespace. What do people think?
I'd vote for one,
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options would be to have one per
database, and one per tablespace. What do people think?
Why do we
Josh,
Just my own two cents. First I am not knocking the work that has been on
autovacuum. I am sure that it was a leap on its own to get it to work.
However I will say that I just don't see the reason for it.
I've personally seen at least a dozen user requests for autovacuum in the
backend,
Josh Berkus wrote:
Not that I don't agree that we need a less I/O intense alternative to VACUUM,
but it seems unlikely that we could actually do this, or even agree on a
spec, before feature freeze.
I don't see the need to rush anything in before the feature freeze.
Wheras integrated AV is
I've personally seen at least a dozen user requests for autovacuum in the
backend, and had this conversation about 1,100 times:
NB: After a week, my database got really slow.
Me: How often are you running VACUUM ANALYZE?
NB: Running what?
Me too. Just hang out in #postgresql for a while :)
On Thu, Jun 16, 2005 at 02:09:47PM +1000, Neil Conway wrote:
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options would be to have one per
Gavin Sherry wrote:
I guess my main concern is that we'll have a solution to the problem of
dead tuples which is only half way there. It is only an incremental
improvement upon the contrib module and solves only one real problem:
users do not read up on VACUUM or autovacuum. This is at the
Joshua D. Drake wrote:
Just my own two cents. First I am not knocking the work that has been
on autovacuum. I am sure that it was a leap on its own to get it to
work. However I will say that I just don't see the reason for it.
The major reasons for autovacuum as I see it are as follows:
*
Neil Conway wrote:
Josh Berkus wrote:
Wheras integrated AV is something we *could* do, and is widely
desired.
I don't see why. IMHO the current autovacuum approach is far from
optimal. If integrated autovacuum just means taking the same
approach and building it into the backend, how does
Simon Riggs [EMAIL PROTECTED] writes:
Looks bad... but how does it look for 1000 inherited relations? My
feeling is that we should not be optimizing the case above 1000
relations. That many partitions is very unwieldy.
Well, it's not so much that I care about queries with 1000+ relations,
as
Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 02:09:47PM +1000, Neil Conway wrote:
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options
Neil Conway wrote:
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options would be to have one per
database, and one per tablespace. What do
Well, it's not so much that I care about queries with 1000+ relations,
as that this is a good way to stress-test the code and find out where
the performance issues are. There are many thousand lines of code that
can never be performance-sensitive, but to expose the ones that are
it helps to push
Marc G. Fournier [EMAIL PROTECTED] writes:
Without more information to provide at this time, does the following seem
unusual?
INFO: free space map: 252 relations, 411494 pages stored; 738640 total pages
needed
DETAIL: Allocated FSM size: 2000 relations + 40 pages = 2463 kB shared
Simon Riggs [EMAIL PROTECTED] writes:
If you really do need that many, you can go to the trouble of grouping
them in two levels of nesting, so you have a root table, multiple month
tables and then each month table with multiple day tables (etc).
I wonder if testing deeply nested inheritance
Alvaro Herrera [EMAIL PROTECTED] writes:
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
Er, what user/password issue? Context please.
The only thing that I'd need to modify is add
56 matches
Mail list logo
