; Could you confirm that your problem cases are actually caused by this
> effect and not something else?
Yes, confirmed. The runaway queries all are joining against an empty
temporary table.
Thanks,
Cristian
--
Cristian Gafton
rPath, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers
it - unless there is some trick to tell the planner that this is a
query that would be much better optimized away instead of causing a massive
IO storm.
Thanks,
Cristian
--
Cristian Gafton
rPath, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-> Hash (cost=946.07..946.07 rows=42807 width=58)
-> Seq Scan on versions (cost=0.00..946.07 rows=42807 width=58)
-> Hash (cost=354.65..354.65 rows=19465 width=23)
-> Seq Scan on items (cost=0.00..354.65 rows=19465 width=23)
(28 rows)
Thanks,
Cri
e oids of the temp
tables it creates and investigate from that angle, but in the meantime is
there any way to reset the stats collector altogether? Could this be a
corrupt stat file that gets read and written right back on every loop
without any sort of validation?
Thanks,
Cristian
--
Cristian
On Tue, 29 Jan 2008, Tom Lane wrote:
Cristian Gafton <[EMAIL PROTECTED]> writes:
Autovacuum is disabled, since the database is mostly read only. There is a
"vacuumdb -a -z" running nightly on the box. However, the application that
queries it does a lot of work with temporar
On Tue, 29 Jan 2008, Tom Lane wrote:
On Tue, 29 Jan 2008, Cristian Gafton wrote:
I have a ~150GB sized server, containing two databases that are active in
mostly read mode. I have noticed lately that the global/pgstat.stat file is
somewhere around 1MB freshly after a restart, but at some point
On Tue, 29 Jan 2008, Cristian Gafton wrote:
I have a ~150GB sized server, containing two databases that are active in
mostly read mode. I have noticed lately that the global/pgstat.stat file is
somewhere around 1MB freshly after a restart, but at some point it baloons to
74MB in size for no
rather
small in size. Am I right to assume that a 74MB pgstat.stat file is not
normal - and what might have caused it?
Thanks,
Cristian
--
Cristian Gafton
rPath, Inc.
---(end of broadcast)---
TIP 5: don't forget to increase your free spac
