Re: [BUGS] BUG #4020: RFE: have way to log autovacuum activity

[Joseph S]

Alvaro Herrera wrote:


Yeah, we have a configurable autovacuum log on 8.3.


Sorry, I looked but didn't see it.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4020: RFE: have way to log autovacuum activity

[Joseph S]

The following bug has been logged online:

Bug reference:  4020
Logged by:  Joseph S
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system:   CentOS 5
Description:RFE: have way to log autovacuum activity
Details: 

When autovacuum decides to vacuum one of our large tables, the whole site
slows down, but it is not always obvious why.  It would be nice if there was
an option to log autovacuum activity so I know how often a vacuum runs and
how long it takes.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] Re: BUG #3500: Horrible performance when wrong type is set in prepared statement

[Joseph S]

Flavio Botelho wrote:


I know the application should not be doing this. But i wonder if lots of the
complaints about postgres performance couldnt be related to problems like
this. I suggest that you change the behaviour of something like that from
silently accepting the string value to throwing an error.

Well that would be bad.  I still have a lot of code with numbers inside 
quotes to work around the old postgres bug where index scans weren't 
used unless the numbers were in quotes (because the table columns were 
int2's and passed in numbers were assumed to be ints)


Do you have EXPLAIN output showing the difference in your queries if the 
values are in strings or not?


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

[BUGS] EXPLAIN ANALYZE for bitmapAnd and bitmapOr scans always reports rows = 0

[Joseph S]

From this snipped you can see that the Bitmap Heap scan returns 123 
rows, but the BitmapAnd under it returns 0.  I would find it useful to 
determine how many rows were thrown out by the recheck.


 ->  Bitmap Heap Scan on d  (cost=4959.18..16848.23 
rows=754 width=10) (actual time=344.126..1534.198 rows=123 loops=1)
   Recheck Cond: ((s = $0) AND (sdate >= 
'2007-06-30'::date) AND (sdate <= '2007-07-30'::date))

   Filter: (snipped filter conditions here)
   ->  BitmapAnd  (cost=4959.18..4959.18 
rows=3218 width=0) (actual time=337.002..337.002 rows=0 loops=1)
 ->  Bitmap Index Scan on d_idx1 
(cost=0.00..1035.58 rows=54796 width=0) (actual time=96.478..96.478 
rows=30338 loops=1)

   Index Cond: (s = $0)
 ->  Bitmap Index Scan on d_idx2 
(cost=0.00..3922.98 rows=183437 width=0) (actual time=235.680..235.680 
rows=181322 loops=1)
   Index Cond: ((sdate >= 
'2007-06-30'::date) AND (sdate <= '2007-07-30'::date))


This was on:
PostgreSQL 8.2.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 
3.4.6 20060404 (Red Hat 3.4.6-3)


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings