Matthew T. O'Connor matthew@zeut.net writes:
None of this directly addresses the question of what the stats system
*should* track, but perhaps it is wrongheaded to totally redesign the
stats system for the purposes of autovacuum.
I'd argue it's fine: there are tons of people using row-level
Tom Lane wrote:
I'd argue it's fine: there are tons of people using row-level stats
via autovacuum, and (AFAICT) just about nobody using 'em for any other
purpose. Certainly you never see anyone suggesting them as a tool for
investigating problems on pgsql-performance. Sure, it's a repurposing
Matthew T. O'Connor matthew@zeut.net writes:
Tom Lane wrote:
the only full solution will involve backends doing some extra work at
subtransaction commit/abort so that they can report properly classified
update counts.
Any guess as to the performance implications?
Pushing some counts from
Tom,
I'd argue it's fine: there are tons of people using row-level stats
via autovacuum, and (AFAICT) just about nobody using 'em for any other
purpose. Certainly you never see anyone suggesting them as a tool for
investigating problems on pgsql-performance.
Actually, I use the stats for
Em Qui, 2006-01-19 às 22:29 +0100, Martijn van Oosterhout escreveu:
Possibly nowhere. But when you send invoices to customers, any details
on there *are* immutable. Sure, in your database you don't care if
things change, but then they don't match reality anymore do they?
Then what you
On Thu, 2006-01-26 at 18:40 -0500, Tom Lane wrote:
You can work around this by doing (as root)
echo 0 /proc/sys/kernel/randomize_va_space
before starting the postmaster. You'll probably want to set it back to
1 when done experimenting with EXEC_BACKEND, since address randomization
is a
Hi,
I noticed that when I install via the msi setup there is a extra DLL in
the bin directory called pthreadGC2.dll. (Posix thread library for windows)
This dll is not in the postgresql-8.1.2-1-binaries-no-installer.zip file.
Postgresql seems to run fine without out when I do a manual
