On Tue, Jan 17, 2006 at 05:12:09PM -0500, Tom Lane wrote:
> However, that's always been the case, so I don't understand
> why your stats file is so much bigger in 8.1. Have you changed your
> vacuuming strategy at all since the 8.0 installation? Perhaps row or
> block statistics weren't enabled i
Marcin <[EMAIL PROTECTED]> writes:
> On Tue, Jan 17, 2006 at 05:12:09PM -0500, Tom Lane wrote:
>> However, that's always been the case, so I don't understand
>> why your stats file is so much bigger in 8.1. Have you changed your
>> vacuuming strategy at all since the 8.0 installation? Perhaps row
Steven Mooij <[EMAIL PROTECTED]> writes:
> LOG: background writer process (PID 8208) was terminated by signal 9
> LOG: terminating any other active server processes
> LOG: statistics collector process (PID 8209) was terminated by signal 9
Kill -9 is not something Postgres ever initiates; where
Tom Lane wrote:
> Stats off and it's still bloating the file??
>
> [ studies code... ] I see the culprit: it's the pgstat_report_vacuum
> and pgstat_report_analyze routines that were added in 8.1. Those send
> messages unconditionally, meaning that the collector will create table
> entries for
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Yeah, row level seems appropiate for what we use it. I'll take care of
> it, unless you want to do it.
I'll fix it --- I want to put in an immediate tabpurge on drop, too.
regards, tom lane
---(end of b
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Given the nature of what's counted, I think that treating these
>> messages as "row level" stats would be appropriate. Alvaro, what do
>> you think?
> Yeah, row level seems appropiate for what we use it. I'll take care of
> it, unle
Tom Lane wrote:
> Actually, there's another problem here: if we do have row-level stats
> turned on, a manual "VACUUM" command will still cause the set of tables
> listed in the stats file to grow to include every table in the DB,
> whether or not anything interesting is happening to that table.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm tempted to change pgstat_recv_vacuum
>> and pgstat_recv_analyze so that they will not create new hash entries,
>> but only insert the row count if the hash entry already exists. I am a
>> bit worried that I might be missing someth
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'm tempted to change pgstat_recv_vacuum
> >> and pgstat_recv_analyze so that they will not create new hash entries,
> >> but only insert the row count if the hash entry already exists. I am a
> >> bit worried th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Well, if you issue a manual vacuum then you can argue that it has been
> "modified" (it's seeing some activity). But immediately after a vacuum
> the table will not be vacuumed by autovac if there's no other activity,
> because there's no need for it, s
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Well, if you issue a manual vacuum then you can argue that it has been
> > "modified" (it's seeing some activity). But immediately after a vacuum
> > the table will not be vacuumed by autovac if there's no other activity,
> > because
Tom Lane wrote:
> [ studies code... ] I see the culprit: it's the pgstat_report_vacuum
> and pgstat_report_analyze routines that were added in 8.1. Those send
> messages unconditionally, meaning that the collector will create table
> entries for every table during a database-wide vacuum, even wit
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe the fact that the stat file is completely rewritten every 500 ms
> should be reconsidered, if in the future someone chooses to rewrite
> the stat system. We can reconsider this part then, as well.
Yeah, it's becoming pretty obvious that that desi
Marcin <[EMAIL PROTECTED]> writes:
> Do you think it will be included in one of next 8.1.x releases, or do I
> have to wait for 8.2?
I'm working on a fix for 8.1.3.
regards, tom lane
---(end of broadcast)---
TIP 1: if postin
Magnus reported a similar problem with path names. I looked at his
statistics and found that even at 100 buckets, his LIKE 'f:/.../%" query
would never span more than one bucket, and because all the path names
were unique, there were no most common values.
In the case where the LIKE hits only on
Hi,
I am migrating from MS SQL to POSTGRESQL database.
In this, I have some problem with the ASP connection. The error is as
follows:
Microsoft OLE DB Provider for ODBC Drivers
(0x80004005)
Error while executing the query; ERROR: SELECT query has no destination for
result data
HINT: If
16 matches
Mail list logo
