Bruce Momjian wrote:
> It is by default for unusual activity. It can be for normal activity
> using the proper GUC settings, but we don't have a way to control
> that just for autovacuum yet, and given what we have in 8.2, I don't
> see a need to add more until users say they need more.
Right, th
Alvaro Herrera wrote:
> On the other hand it doesn't break CVS tip at all, i.e. I can perfectly
> create the view and it works. (I can even call it "*NEW*").
Actually CVS tip seems a bit broken,
alvherre=# \d "*NEW*"
Vista «public.*NEW*»
Columna | Tipo | Modificadores
-+
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Another question. The patch does a lot of scanning of the range table
> searching for specific aliases for things -- usually for *NEW* or *OLD*,
> but also to get the entry for the view we are modifying, etc. This
> seems pretty fragile -- it breaks if
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm rewriting several parts of the patch, and have a question. Can I
> > assume that there is only one rule on the CMD_SELECT event, for any
> > given view?
>
> Yeah. See the restrictions enforced by DefineQueryRewrite() for
> deta
ITAGAKI Takahiro wrote:
> Suppose a simple update case, for example, the accounts table in pgbench.
> The default fillfactor of btree indexes is 90%, so the leaf pages are
> fully split after we update 10-20% of tuples. But pgstatindex reports
> the fragmentation is 50% in such condition, but I thi
Satoshi Nagayasu <[EMAIL PROTECTED]> wrote:
> > I hope you to write how to interpret the framgentation (and other) info
> > in README. In my understanding, I'll write "You'd better do REINDEX when
> > you see the fragmentation is greater than 50%" under the present
> > calculation method.
>
> I
ITAGAKI Takahiro wrote:
> Satoshi Nagayasu <[EMAIL PROTECTED]> wrote:
>
>> Well, in that way, following two conditions,
>>[1] [x] [2] [y] [3]
>> and
>>[3] [x] [2] [y] [1]
>> will be calculated as same fragmentation ratio(100%), I can't agree
>> with that, because both will generate differe
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> How do you figure that? The point of logging what's done is so that you
> >> can find out what autovac has been doing, not what it's doing right now.
>
> > I don't think the server logs is the place to record his
On Thu, Aug 17, 2006 at 08:52:45PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Something else -- on the rewrite code I see mentioned a lot of times the
> > acronym RIR (like in fireRIRrules); what does RIR stand for? I can't
> > find it anywhere.
>
> Damifino ... Jan m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How do you figure that? The point of logging what's done is so that you
>> can find out what autovac has been doing, not what it's doing right now.
> I don't think the server logs is the place to record history autovacuum
> activity.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm rewriting several parts of the patch, and have a question. Can I
> assume that there is only one rule on the CMD_SELECT event, for any
> given view?
Yeah. See the restrictions enforced by DefineQueryRewrite() for
details. There's also a unique in
Satoshi Nagayasu <[EMAIL PROTECTED]> wrote:
> Well, in that way, following two conditions,
>[1] [x] [2] [y] [3]
> and
>[3] [x] [2] [y] [1]
> will be calculated as same fragmentation ratio(100%), I can't agree
> with that, because both will generate different costs while index scan
> in th
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 17, 2006 at 03:09:30PM -0400, Alvaro Herrera wrote:
>> I have had an idea for some time that is actually much simpler -- just
>> launch several backends at once to do different things, and randomly
>> send SIGSTOP and SIGCONT to each. If the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Have you tried to use debbugs? I agree with Greg Stark that it's a
> better fit for our current procedure, while enabling better
> traceability.
The principal strike against debbugs seems to be that the source code is
not readily available and/or isn't
ITAGAKI Takahiro wrote:
> But the method has the above problem. So I suggest to use whether
> the right link points to the next adjacent page or not.
>
> if (opaque->btpo_next != P_NONE && opaque->btpo_next != blkno + 1)
> stat->fragments++;
Well, in that way, following two conditions,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jim C. Nasby wrote:
> >> If there was a mechanism to obtain
> >> field widths from the catalog there would be no need to store the
> >> field width in each tuple. This would be useful for other types as
> >> well (UUID and ENUM, for ex
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Revised patch enclosed, now believed to be production ready. This
implements regular log switching using the archive_timeout GUC.
Further patch enclosed implementing these changes plus the record type
version of pg_xlogfile_name_offset()
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed. I just IM'ed Alvaro and he says pg_stat_activity should now
> > show exactly what autovacuum is doing (and if it doesn't, let's fix it).
> > I think that is the best solution to the monitoring problem, rather than
> > throwing
Simon Riggs <[EMAIL PROTECTED]> writes:
>> Revised patch enclosed, now believed to be production ready. This
>> implements regular log switching using the archive_timeout GUC.
> Further patch enclosed implementing these changes plus the record type
> version of pg_xlogfile_name_offset()
Applied w
Hi,
I'm reworking Bernd's updatable views patch. I haven't found any
showstoppers yet, which doesn't mean there aren't any. On the other
hand, the functionality is severely limited, per spec, so really the
thing is not all that difficult.
I'm rewriting several parts of the patch, and have a que
Larry Rosenman wrote:
> Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> >> Matthew T. O'Connor wrote:
> >>> Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
>
> > Any chance we can make this change before release? I think it's
> > very important to be able to look through the
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Matthew T. O'Connor wrote:
>>> Bruce Momjian wrote:
Matthew T. O'Connor wrote:
> Any chance we can make this change before release? I think it's
> very important to be able to look through the logs and *know*
> that you tables
On Thu, Aug 17, 2006 at 02:54:20PM -0500, Jim C. Nasby wrote:
> On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout wrote:
> > On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
> > > But the method has the above problem. So I suggest to use whether
> > > the right link
Peter Eisentraut wrote:
> Alvaro Herrera wrote:
> > Have you tried to use debbugs?
>
> If you can find up-to-date source code for debbugs, we might continue
> that line of thought.
Josh Berkus said he'd try to talk to the Debian people at LinuxWorld --
let's see if something materializes from th
Alvaro Herrera wrote:
> Have you tried to use debbugs?
If you can find up-to-date source code for debbugs, we might continue
that line of thought.
The searching capabilities in debbugs are, well, non-existent, which is
a real problem in my mind.
--
Peter Eisentraut
http://developer.postgresql
On Thu, Aug 17, 2006 at 03:17:07PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed. I just IM'ed Alvaro and he says pg_stat_activity should now
> > show exactly what autovacuum is doing (and if it doesn't, let's fix it).
> > I think that is the best solution to the mo
Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
> > Bruce Momjian wrote:
> > >Matthew T. O'Connor wrote:
> > >
> > >>Any chance we can make this change before release? I think it's very
> > >>important to be able to look through the logs and *know* that you tables
> > >>are getting vacuumed
On Thu, Aug 17, 2006 at 03:09:30PM -0400, Alvaro Herrera wrote:
> stark wrote:
>
> > Actually I was already looking into a related issue and have some work here
> > that may help with this.
> >
> > I wanted to test the online index build and to do that I figured you needed
> > to
> > have regres
On Thu, Aug 17, 2006 at 04:17:01PM +0100, stark wrote:
> I wanted to test the online index build and to do that I figured you needed to
> have regression tests like the ones we have now except with multiple database
> sessions. So I hacked psql to issue queries asynchronously and allow multiple
> d
On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout wrote:
> On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
> > I think this condition should be regarded as full-fragmented,
> > but pgstatindex reports that the leaf_fragmentation is 50%.
> >
> > Presently, fragmenta
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> >> ... Red Hat's present bugzilla system
> >> could be described that way --- and while I can't say I'm in
> >> love with it, I can deal with it.
>
> > Doesn't bugzilla insist on sending you the complete bug every time?
>
> Nope
On 8/17/06 12:29 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Jie Zhang" <[EMAIL PROTECTED]> writes:
>> This sounds good. Another problem is about ScalarArrayOpExpr support in
>> current nodeBitmapIndexscan. This will not work for stream bitmaps.
>
> Sure it will; it's just an OR.
>
Yes, it i
Tom Lane wrote:
Doesn't bugzilla insist on sending you the complete bug every time?
Nope, it just sends the changes/additions. Other than the lack of a
direct email input method, I find BZ quite usable. Josh was just
complaining that its source code is a mess (dunno, haven't looked)
but
"Jie Zhang" <[EMAIL PROTECTED]> writes:
> This sounds good. Another problem is about ScalarArrayOpExpr support in
> current nodeBitmapIndexscan. This will not work for stream bitmaps.
Sure it will; it's just an OR.
> We have to disable it in the optimizer.
That's not happening ;-)
Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote:
I've yet to see a bug tracker that doesn't make it trivial to
identify bugs that were marked as invalid (ie: not a real
bug). The only difference is that you actually have to mark
Well, if it's inva
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed. I just IM'ed Alvaro and he says pg_stat_activity should now
> show exactly what autovacuum is doing (and if it doesn't, let's fix it).
> I think that is the best solution to the monitoring problem, rather than
> throwing lines in the server logs.
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> ... Red Hat's present bugzilla system
>> could be described that way --- and while I can't say I'm in
>> love with it, I can deal with it.
> Doesn't bugzilla insist on sending you the complete bug every time?
Nope, it just sends the changes/addi
On 8/17/06 5:54 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Jie Zhang" <[EMAIL PROTECTED]> writes:
>> This sounds great. One thing I am concern about is that this will add the
>> dependency of node types into the access methods. If we still keep
>> nodeBitmapIndexscan and let it do the bitmap co
stark wrote:
> Actually I was already looking into a related issue and have some work here
> that may help with this.
>
> I wanted to test the online index build and to do that I figured you needed to
> have regression tests like the ones we have now except with multiple database
> sessions. So I
On Thu, Aug 17, 2006 at 01:47:37PM -0400, Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >Matthew T. O'Connor wrote:
> >
> >>I assume you are suggesting that the base value be 0? Well for one
> >>thing if the table doesn't have any rows that will result in constant
> >>vacuuming of that
On Thu, Aug 17, 2006 at 01:29:57PM -0400, Matthew T. O'Connor wrote:
> Josh Berkus wrote:
> >>Is it time to turn on autovacuum by default in 8.2? I know we wanted
> >>to be on the side of caution with 8.1, but perhaps we should evaluate
> >>the experiences now. Comments?
> >
> >I'm in favor of
On Thu, Aug 17, 2006 at 01:42:20PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jim C. Nasby wrote:
> >> If there was a mechanism to obtain
> >> field widths from the catalog there would be no need to store the
> >> field width in each tuple. This would be useful for other
On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote:
> > I've yet to see a bug tracker that doesn't make it trivial to
> > identify bugs that were marked as invalid (ie: not a real
> > bug). The only difference is that you actually have to mark
> Well, if it's invalid, it shouldn't b
On Thu, Aug 17, 2006 at 07:00:21PM +0200, Magnus Hagander wrote:
> > These days I doubt there's anyone around the project who
> > refuses to use a web browser at all. However, I still
> > personally find it much more convenient to read and respond
> > to mailing-list postings than to have to go
Peter Eisentraut wrote:
Arturo Pérez wrote:
The DBA therefore pokes the
right information into
the planner's statistical tables (or, perhaps, a more human-
manageable one that gets
"compiled" into the planner's stats).
I think we're perfectly capable of producing a system that can collect
the
> > >> Since buffer commands all have a single char I wanted a single char one
> > >> too. The "c" for "cursor" was taken already, so i choose the "u" (second
> > >> char in "cursor"). If somebody has a better suggestion, let us know ;)
> >
> > > I think a new backslash variable isn't the way to
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
I assume you are suggesting that the base value be 0? Well for one
thing if the table doesn't have any rows that will result in constant
vacuuming of that table, so it needs to be greater than 0. For a small
table, say 100 rows, there usual
Matthew T. O'Connor wrote:
> Jim C. Nasby wrote:
> >Actually, on a table small enough for the thresholds to kick in it's
> >going to be extremely fast to vacuum anyway, and the table is probably
> >either static or changing very rapidly. I'm wondering if maybe they
> >should just default to 0?
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> If there was a mechanism to obtain
>> field widths from the catalog there would be no need to store the
>> field width in each tuple. This would be useful for other types as
>> well (UUID and ENUM, for example).
> I don't think the
Arturo Pérez wrote:
> The DBA therefore pokes the
> right information into
> the planner's statistical tables (or, perhaps, a more human-
> manageable one that gets
> "compiled" into the planner's stats).
I think we're perfectly capable of producing a system that can collect
the statistics. We j
Larry Rosenman wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Well, the problem is that it shows what it's *currently* doing, but it
doesn't let you know what has happened in the last day or whatever.
It can't answer "has table foo been vacuumed recently?" or "what
tables haven't be
Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 12:41:57PM -0400, Matthew T. O'Connor wrote:
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
Autovacuum can cause unpredictable performance issues, that is if it
vacuums in the middle of a busy day and
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
> >Matthew T. O'Connor wrote:
> >
> >>Any chance we can make this change before release? I think it's very
> >>important to be able to look through the logs and *know* that you tables
> >>are getting vacuumed or not.
> >>
> >
> >Agreed. I
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > Larry Rosenman wrote:
> >> Alvaro Herrera wrote:
> >>> Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
> > Bruce Momjian wrote:
> >> Matthew T. O'Connor wrote:
> >>
> >>> and increasing the log level when autovacuum actually f
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Chris Mair wrote:
> >> Since buffer commands all have a single char I wanted a single char one
> >> too. The "c" for "cursor" was taken already, so i choose the "u" (second
> >> char in "cursor"). If somebody has a better suggestion, l
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Alvaro Herrera wrote:
>>> Bruce Momjian wrote:
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
>> Matthew T. O'Connor wrote:
>>
>>> and increasing the log level when autovacuum actually fires off
>>> a VACUUM or ANALYZE com
Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 03:00:00PM +0900, ITAGAKI Takahiro wrote:
IMO, the only reason at all for naptime is because there is a
non-trivial cost associated with checking a database to see if any
vacuuming is needed.
This cost is reduced significantly in the integrated
Larry Rosenman wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >> Matthew T. O'Connor wrote:
> >>> Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
>
> > and increasing the log level when autovacuum actually fires off a
> > VACUUM or ANALYZE command.
> >
>
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Matthew T. O'Connor wrote:
> > > Bruce Momjian wrote:
> > > > Matthew T. O'Connor wrote:
> > > >
> > > >> and increasing the log level when autovacuum actually fires off a
> > > >> VACUUM
> > > >> or ANALYZE command.
> > > >>
> > > >
> > >
On Thu, Aug 17, 2006 at 12:41:57PM -0400, Matthew T. O'Connor wrote:
> Peter Eisentraut wrote:
> >Is it time to turn on autovacuum by default in 8.2? I know we wanted to
> >be on the side of caution with 8.1, but perhaps we should evaluate the
> >experiences now. Comments?
>
> Would be fine by
Josh Berkus wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted
to be on the side of caution with 8.1, but perhaps we should evaluate
the experiences now. Comments?
I'm in favor of this, but do we want to turn on vacuum_delay by default
as well?
I thought about thi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Chris Mair wrote:
>> Since buffer commands all have a single char I wanted a single char one
>> too. The "c" for "cursor" was taken already, so i choose the "u" (second
>> char in "cursor"). If somebody has a better suggestion, let us know ;)
> I think a
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> Matthew T. O'Connor wrote:
>>> Bruce Momjian wrote:
Matthew T. O'Connor wrote:
> and increasing the log level when autovacuum actually fires off a
> VACUUM or ANALYZE command.
>
This was not done because the logging
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Any chance we can make this change before release? I think it's very
important to be able to look through the logs and *know* that you tables
are getting vacuumed or not.
Agreed. I just IM'ed Alvaro and he says pg_stat_activity should
Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
> > Bruce Momjian wrote:
> > > Matthew T. O'Connor wrote:
> > >
> > >> and increasing the log level when autovacuum actually fires off a VACUUM
> > >> or ANALYZE command.
> > >>
> > >
> > > This was not done because the logging control only
Joe Conway <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Then why bother with two different lists?
>>
>> If developers need to be on both list (which I beleive they do), and the
>> focus of both lists is developers, then why not just remove one of them
>> and get rid of the problem?
> I
On Thu, Aug 17, 2006 at 09:20:43AM -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Ever since pgsql-patches replies started going to -hackers, threading
> > doesn't work anymore, so I for one can't tell what this refers to at
> > all.
>
> Yeah, that experiment hasn't se
> On Aug 17, 2006, at 9:30 AM, Magnus Hagander wrote:
>
> > Then why bother with two different lists?
> >
> > If developers need to be on both list (which I beleive they do), and the
> > focus of both lists is developers, then why not just remove one of them
> > and get rid of the problem?
Di
On Thu, Aug 17, 2006 at 03:00:00PM +0900, ITAGAKI Takahiro wrote:
>
> "Matthew T. O'Connor" wrote:
>
> Sorry, I should have explained more.
>
> > What is this based on? That is, based on what information is it
> > deciding to reduce the naptime?
>
> If there are some vacuum or analyze jobs,
Jim C. Nasby wrote:
> On Wed, Aug 16, 2006 at 07:21:06PM -0400, Gregory Stark wrote:
> > This is the same issue we have with char(n) and numeric(x,y) already. If we
> > found a general solution for getting the type name to the enum would it also
> > help getting the typmod to char(n) and numeric(x,
--On Dienstag, August 15, 2006 16:33:27 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
I'm tempted to suggest that the RETURNING commands might need to be
separate rule events, and that to support this you'd need to write
an additional rule:
CREATE RULE r1 AS ON INSERT RETURNING TO myview DO
RT has an E-mail interface. That was one of our considerations
when we used it to replace our aging trouble ticket system. What
does the interface need to do? RT's is pretty flexible.
Ken
On Tue, Aug 15, 2006 at 04:59:46PM -0500, Jim C. Nasby wrote:
> On Tue, Aug 15, 2006 at 10:53:28AM -0500, Ken
On Wed, Aug 16, 2006 at 01:22:43PM +0900, Michael Glaesemann wrote:
>
> On Aug 16, 2006, at 12:29 , Tom Lane wrote:
>
> >So my current take on this would be that the bug tracker
> >would have to have a reasonable "output" email capability, but I'd not
> >necessarily insist on being able to "input
On Aug 15, 2006, at 10:40 AM, Jim C. Nasby wrote:
On Mon, Aug 14, 2006 at 11:41:29PM +0300, Hannu Krosing wrote:
??hel kenal p??eval, E, 2006-08-14 kell 18:21, kirjutas Peter
Eisentraut:
Perez wrote:
I thought, from watching the list for a while, that the planner
statistics needed were know
> Alvaro Herrera writes:
>> Maybe we could write a suitable test case using Martijn's concurrent
>> testing framework.
>
> The trick is to get process A to commit between the times that process B
> looks at the new and old versions of the pg_class row (and it has to
> happen to do so in that ord
On Wed, Aug 16, 2006 at 06:52:21AM +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
> > that the bug tracker would have to have a reasonable "output" email
> > capability, but I'd not necessarily insist on being able to "input"
> > to it by mail. Red Hat's present bugzilla system could be describe
Chris Mair wrote:
>
> > > > BTW, \u seems not to have any mnemonic value whatsoever ... isn't there
> > > > some other name we could use?
> > >
> > > True :)
> > > Since buffer commands all have a single char I wanted a single char one
> > > too. The "c" for "cursor" was taken already, so i choos
On Wed, Aug 16, 2006 at 07:21:06PM -0400, Gregory Stark wrote:
> This is the same issue we have with char(n) and numeric(x,y) already. If we
> found a general solution for getting the type name to the enum would it also
> help getting the typmod to char(n) and numeric(x,y)? Would it let us store
>
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
> > Matthew T. O'Connor wrote:
> >
> >> and increasing the log level when autovacuum actually fires off a VACUUM
> >> or ANALYZE command.
> >>
> >
> > This was not done because the logging control only for autovacuum was
> > going to be add
> > > BTW, \u seems not to have any mnemonic value whatsoever ... isn't there
> > > some other name we could use?
> >
> > True :)
> > Since buffer commands all have a single char I wanted a single char one
> > too. The "c" for "cursor" was taken already, so i choose the "u" (second
> > char in "c
Peter,
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
I'm in favor of this, but do we want to turn on vacuum_delay by default
as well?
--Josh
-
> > This, however, I would find very useful - both as a -hacker
> and as a
> > user. The point is that only confirmed things should be in
> there, so
> > only confirmed things should be returned on searches and whatevr.
> > (private not as in not visible to the public, but private as in
> > wri
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a VACUUM
or ANALYZE command.
This was not done because the logging control only for autovacuum was
going to be added. Right now, if you want to see the vacuum activity,
you
> These days I doubt there's anyone around the project who
> refuses to use a web browser at all. However, I still
> personally find it much more convenient to read and respond
> to mailing-list postings than to have to go and visit random
> web pages to find out if there's something I need to
Magnus Hagander wrote:
> > > I'm not sure I follow this, since currently anyone can
> > email the bugs
> > > list or use the bugs -> email form from the website. Are
> > you looking
> > > to increase the barrier for bug reporting?
> >
> > Any garbage (ie. spam) is generally filtered before it
On Thu, Aug 17, 2006 at 06:48:54PM +0200, Magnus Hagander wrote:
> This, however, I would find very useful - both as a -hacker and as a
> user. The point is that only confirmed things should be in there, so
> only confirmed things should be returned on searches and whatevr.
> (private not as in not
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
> > Matthew T. O'Connor wrote:
> >
> >> Would be fine by me, but I'm curious to see what the community has to
> >> say. A few comments:
> >>
> >> Autovacuum can cause unpredictable performance issues, that is if it
> >> vacuums in the middle o
Rod Taylor wrote:
The defaults could be a little more aggressive for both vacuum and
analyze scale_factor settings; 10% and 5% respectively.
I would agree with this, not sure of 10%/5% are right, but the general
feedback I have heard is that while the defaults in 8.1 are much better
than the
> > I'm not sure I follow this, since currently anyone can
> email the bugs
> > list or use the bugs -> email form from the website. Are
> you looking
> > to increase the barrier for bug reporting?
>
> Any garbage (ie. spam) is generally filtered before it hits
> the -bugs list itself
Spam:
Guillaume Smet has asked how the new protocol-level bind parameters in
the log file can be processed cleanly by scripts, especially if
double-quotes appear in the string.
I think the fix is to use single quotes for bind strings, rather than
double quotes, and to double literal single quotes in the
> >>> I'd vote for reverting to the old way. Anyone serious
> about hacking
> >>> should be on both lists.
> >
> > Then why bother with two different lists?
> >
> > If developers need to be on both list (which I beleive they
> do), and
> > the focus of both lists is developers, then why not jus
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
Autovacuum can cause unpredictable performance issues, that is if it
vacuums in the middle of a busy day and people don't want that, of
course they t
> > Patch with fix against current CVS is attached.
Forgot the attachment... soory.
--
Chris Mair
http://www.1006.org
diff -rc pgsql.original/doc/src/sgml/ref/psql-ref.sgml pgsql/doc/src/sgml/ref/psql-ref.sgml
*** pgsql.original/doc/src/sgml/ref/psql-ref.sgml 2006-08-17 16:50:58.0 +0
Replying to myself...
> Patch with fix against current CVS is attached.
Alvaro Herrera sent two fixes off-list: a typo and
at the end of SendQueryUsingCursor I sould COMMIT, not ROLLBACK.
So, one more version (6) that fixes these too is attached.
Bye, Chris.
PS: I'm keeping this on both lists
Matthew T. O'Connor wrote:
> Peter Eisentraut wrote:
> > Is it time to turn on autovacuum by default in 8.2? I know we wanted to
> > be on the side of caution with 8.1, but perhaps we should evaluate the
> > experiences now. Comments?
>
> Would be fine by me, but I'm curious to see what the co
> Well, you need to get some agreement on what the bug tracker
> is for. Is
> it:
>
> a) a front-end to deal with complaints and bugs people have.
> Is it something you expect end users to look at? This is how
> Debian uses its bug-tracker, to make sure issues people bring
> up don't get lost.
On Thu, 2006-08-17 at 18:32 +0200, Peter Eisentraut wrote:
> Is it time to turn on autovacuum by default in 8.2? I know we wanted to
> be on the side of caution with 8.1, but perhaps we should evaluate the
> experiences now. Comments?
I would say yes.
I use it on 2 databases over the 200GB ma
Peter Eisentraut wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
Aut
On Aug 17, 2006, at 9:30 AM, Magnus Hagander wrote:
Ever since pgsql-patches replies started going to -hackers,
threading doesn't work anymore, so I for one can't tell what this
refers to at all.
Yeah, that experiment hasn't seemed to work all that well for me
either. Do you have another ide
Magnus Hagander wrote:
Then why bother with two different lists?
If developers need to be on both list (which I beleive they do), and the
focus of both lists is developers, then why not just remove one of them
and get rid of the problem?
I wouldn't argue with that. It would be at least equally
1 - 100 of 133 matches
Mail list logo
