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
http://d
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
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
> >
> 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 mor
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 experienc
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 ha
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 :
Case:
a) If the descriptor of S indicates that
it represents a column of which some
"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 f
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... :)
>
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_NON
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 othe
"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 t
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=sponge&dt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
then tries to vacu
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=sponge&dt=2006-08-16%2021:30:02
>
> Vacuum's always had a race condition: it makes a list of rel O
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 bu
ITAGAKI Takahiro wrote:
"Matthew T. O'Connor" 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, the naptime
is l
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 a
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 al
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> I've still biten by a single "write past chunk" error while returning a
> record in PL/scheme:
> WARNING: problem in alloc set ExprContext: detected write past chunk
> end in block 0x84a0598, chunk 0x84a0c84
The actual bug, almost certainly, is tha
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
> reasona
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 th
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 sure
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 mu
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 j
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 broadcast)
> 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 o
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
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
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 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
> 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.
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
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
> >>> 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
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'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:
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 o
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
> 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
> > wri
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 add
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 describe
> 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 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
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
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 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
"e
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 i
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 +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 "c
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
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 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,
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
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
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
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
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
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
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
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.
> > > >>
> > > >
> > >
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.
> >
>
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
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
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
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
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 be
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
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
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?
> >
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
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
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 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 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: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
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 co
"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
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.
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
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
> > >> 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
"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 ;-)
1 - 100 of 133 matches
Mail list logo
