. Fixed all regressions in contrib (gist indexed) modules
. Fixed a bug that occurs when a compressed datum ends up under 128 bytes
. Fixed a bug on zero-column tuples
. Added regression tests
http://community.enterprisedb.com/varlena/patch-varvarlena-16.patch.gz
--
Gregory Stark
log_autovacuum = on produces a single line of output from autovacuum,
with additional useful stats. Patch is proving useful in performance
testing. Not sure what is intended on logging for 8.3
LOG: autovac public.w scans:1 pages:197(-0) tuples:2338(-7199) CPU
0.00s/0.00u sec elapsed 0.39 sec
On Thu, 2007-03-08 at 15:44 +, Simon Riggs wrote:
Docs included
Just noticed a typo. File mentioned in func.sgml, line 11049 should be
filenamesrc/include/access/htup.h/ and not
filenamesrc/include/storage/bufpage.h/
--
Simon Riggs
EnterpriseDB
On Thu, 2007-03-08 at 16:05 +, Simon Riggs wrote:
LOG: autovac public.w scans:1 pages:197(-0) tuples:2338(-7199) CPU
0.00s/0.00u sec elapsed 0.39 sec
Seems like a pretty cryptic log format to me.
-Neil
---(end of broadcast)---
TIP 5:
Simon Riggs wrote:
log_autovacuum = on produces a single line of output from autovacuum,
with additional useful stats. Patch is proving useful in performance
testing. Not sure what is intended on logging for 8.3
LOG: autovac public.w scans:1 pages:197(-0) tuples:2338(-7199) CPU
On March 8, 2007 09:53 am, Alvaro Herrera wrote:
Simon Riggs wrote:
log_autovacuum = on produces a single line of output from autovacuum,
with additional useful stats. Patch is proving useful in performance
testing. Not sure what is intended on logging for 8.3
LOG: autovac public.w
Darcy Buskermolen wrote:
On March 8, 2007 09:53 am, Alvaro Herrera wrote:
Keep in mind that it's going to be translated, so it's not useful for
machine parsing anyway.
This goes back to the request for vacuum loging to a table..
That's right, but please let's have at least *something*.
On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
Maybe something like this is better:
LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199,
2338 remain CPU usage: whatever
CONTEXT: Automatic vacuuming of table database.public.w
Yours is better.
I've
On 3/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I tried this patch bug found this regression failure:
-- Considering only built-in procs (prolang = 12), look for multiple uses
-- of the same internal function (ie, matching prosrc fields). It's OK to
-- have several entries with
Tatsuhito Kasahara wrote:
Hello.
I found a bug in contrib/pgstatindex.c to reports a strange value of
leaf_fragmentation with some cases.
#Look the following test example.
In GetBTPageStatistics(), stat-fragments is not initialized properly
so that invalid leaf_fragments values are
Alvaro Herrera wrote:
Right. Checking that code, it seems btpo.xact is also being incorrectly
handled, is it not? Incidentally, the return value seems a bit useless.
Then again, this looks bogus as well. (Sorry for the unidiff -- I had to
use interdiff to get it).
--
Alvaro Herrera
Hi.
Alvaro Herrera wrote:
In GetBTPageStatistics(), stat-fragments is not initialized properly
so that invalid leaf_fragments values are inserted in results.
Right. Checking that code, it seems btpo.xact is also being incorrectly
handled, is it not?
Yeah, I think so.
Incidentally, the
Hi,
On 3/9/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
Maybe something like this is better:
LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed
7199, 2338 remain CPU usage: whatever
CONTEXT: Automatic vacuuming of
13 matches
Mail list logo
