Matthew T. O'Connor matthew@zeut.net 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, the naptime is shortened
(i.e, autovacuum is accelerated). And if there
Andrew Dunstan wrote:
I have just noticed that psql's \timing does not apply to internal
commnds like \copy, which surprised me a bit. Is there any reason why it
should not apply at least in the case of \copy, which after all does
real work, as opposed to to the client housekeeping and
Let me add that most entries that illict a quick patch or TODO item do
not come in through the bugs list, but are rather problems people post
to ther lists, or are the result of discussions.
---
Gregory Stark wrote:
Andrew
Tom Lane wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't
there some other name we could use?
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.
--
Peter Eisentraut
Peter Eisentraut wrote:
Tom Lane wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't
there some other name we could use?
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.
On Thu, 2006-08-17 at 03:14 -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't
there some other name we could use?
Ever since pgsql-patches replies started going to -hackers, threading
doesn't work
It occurs to me that what tbm_begin_iterate really is is a constructor
for a stream bitmap object that reads out the contents of a tbm bitmap
(we need a decent name for the non-stream data structure ... maybe
hash bitmap?). If we think of it like that then we can unify the
ideas some more.
Hi,
what's up with the news server? My reader can't connect since yesterday
evening (MESZ, UTC+2). Telnetting gives:
[EMAIL PROTECTED]:~$ telnet news.postgresql.org nntp
Trying 200.46.204.72...
telnet: Unable to connect to remote host: Connection refused
A note about my current NNTP
Gregory Stark wrote:
I'm not sure it's worth throwing out the more user-friendly interface
we have now but I think it's clear that a table is the obvious
machine-readable format if you're already sitting in an SQL
database... :)
Then again, a table might not be the optimal format for an
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] 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
Hi,
after some more reading, I am finally starting
to grasp what Tom Lane meant with action at a
distance. I outline below the information that
I collected from the SQL2003 standard.
Under section 11.5 default clause:
Case:
a) If the descriptor of S indicates that
it represents a column of
Tom Dunstan [EMAIL PROTECTED] writes:
I didn't really want to go down that path in this thread
since it would turn what should be a fairly non-intrusive
patch to add a new type into a big thing, and I really just
wanted to get enums in. :) I tend to think of it the other
way around from how
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I'm not sure it's worth throwing out the more user-friendly interface
we have now but I think it's clear that a table is the obvious
machine-readable format if you're already sitting in an SQL
database... :)
Then again,
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, fragmentation factor is computed as the code below:
if (opaque-btpo_next != P_NONE
Greg Stark wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
I didn't really want to go down that path in this thread
since it would turn what should be a fairly non-intrusive
patch to add a new type into a big thing, and I really just
wanted to get enums in. :) I tend to think of it the other
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 construction for tids returned
by amgetmulti.
No, I'm assuming the
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
maybe the following buildfarm report means that we need a new theory :-(
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spongedt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
then tries to vacuum
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
maybe the following buildfarm report means that we need a new theory :-(
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spongedt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
On Aug 16 04:20, Volkan YAZICI wrote:
On Aug 16 03:09, Volkan YAZICI wrote:
WARNING: problem in alloc set ExprContext: detected write past chunk
end in block 0x8462f00, chunk 0x84634c8
WARNING: cache reference leak: cache pg_type (34), tuple 2/7 has
count 1
Excuse me for bugging the
ITAGAKI Takahiro wrote:
Matthew T. O'Connor matthew@zeut.net wrote:
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, the naptime is shortened
(i.e, autovacuum is accelerated). And if there are no jobs,
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 seemed to work all that well for me
either. Do you have another idea to
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 seemed to work all that well for me
either. Do you have
Joe Conway wrote:
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 seemed to work all that well for me
Tom, all:
I thought the strategy was to provide a way to subscribe to
pgsql-patches, get the text of the messages, and not get the
attachments. Was that techincally infeasable?
--Josh
---(end of broadcast)---
TIP 4: Have you searched our list
Hi,
thanks for reviewing this :)
attached is the new and fixed version of the patch for selecting
large result sets from psql using cursors.
The is_select_command bit is wrong because it doesn't allow for left
parentheses in front of the SELECT keyword (something entirely
reasonable
Matthew T. O'Connor wrote:
My vision of the maintenance window has always been very simple, that
is, during the maintenance window the thresholds get reduced by some
factor (probably a GUC variable) so during the day it might take 1
updates on a table to cause a vacuum but during the
Greg,
In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing anyways.
RT can be set up similarly but I'm not sure how much work it would
Josh Berkus schrieb:
Greg,
In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing
anyways.
RT can be set up similarly but I'm not
Tom Lane wrote:
Yeah, that experiment hasn't seemed to work all that well for me
either. Do you have another idea to try, or do you just want to
revert to the old way?
Since almost the first day I hacked on PostgreSQL I have been filtering
both lists into the same folder, so they pretty much
Peter Eisentraut wrote:
Tom Lane wrote:
Yeah, that experiment hasn't seemed to work all that well for me
either. Do you have another idea to try, or do you just want to
revert to the old way?
Since almost the first day I hacked on PostgreSQL I have been filtering
both lists into the
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 idea to try, or do you just want to
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?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
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?
FWIW, the win32 installer has enalbed autovacuum by default already in
8.1. So it's definitly received a fair amount of
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
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
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:
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 mark
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 community
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
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 just
remove one of
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
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: Yes.
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
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 of a busy day and
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
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 hits
the
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
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
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
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
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 added. Right now, if
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
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 described
that
Alvaro Herrera alvherre ( at ) commandprompt ( dot ) com 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
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
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 to it by
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,
--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
Alvaro Herrera wrote:
My vision is a little more complex than that. You define group of
tables, and separately you define time intervals. For each combination
of group and interval you can configure certain parameters, like a
multiplier for the autovacuum thresholds and factors; and also the
Chris Mair wrote:
At some point we ought to extend libpq enough to expose the V3-protocol
feature that allows partial fetches from portals; that would be a
cleaner way to implement this feature. However since nobody has yet
proposed a good API for this in libpq, I don't object to
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
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
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 cursor). If somebody
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 choose the u (second
char
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,y)?
On Thu, Aug 17, 2006 at 03:00:00PM +0900, ITAGAKI Takahiro wrote:
Matthew T. O'Connor matthew@zeut.net 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
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 seemed to
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?
Didn't I say
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 wouldn't
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 for autovacuum was
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
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 control only for autovacuum
was
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 new backslash
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
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 me, but
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
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.
This was not done because the logging
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
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 command.
This was not done because
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 fires off
a VACUUM or ANALYZE command.
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 just IM'ed Alvaro
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
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 been
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 just
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 there is
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?
I
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
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
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 and
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 be in
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 types as
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 this, but do
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 table, so it
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 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 construction for
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/additions.
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.
How
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
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, let us know ;)
I
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 go. I would use a
1 - 100 of 134 matches
Mail list logo
