On Thu, 2005-06-16 at 01:10 -0400, Greg Stark wrote:
> 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
On Thu, 16 Jun 2005, Matthew T. O'Connor wrote:
> 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:
> >user
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
On Thu, 2005-06-16 at 00:44 -0400, Matthew T. O'Connor wrote:
> 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
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 inherita
"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
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
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 peop
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
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,
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 do
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:
* R
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 expen
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
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 whi
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
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
backe
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
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,
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
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 l
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
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 use
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 t
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
Bruce Momjian 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 searched our list arc
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 m
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 be
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
data
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.
---
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 def
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_autova
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 2
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
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 wo
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
autovacuum_vacu
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 into
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 h
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
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 datab
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 ru
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 searc
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: "
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 invo
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
autovacuu
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, unfortu
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 cle
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
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 conce
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 tha
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? Al
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 will
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
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_aut
"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 obvi
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_t
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 paramet
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 fr
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).
> >
> >
59 matches
Mail list logo
