[PERFORM] deadlock_timeout affect on performance

[pg noob]

Hi all,

I have a question about the deadlock_timeout in regards to performance.
Right now we have this timeout set at its default of 1s.
My understanding of it is that this means that every 1 second the server
will check for deadlocks.
What I am wondering is how much of a performance improvement we would
expect to get if this was raised to 30 seconds?
Is it negligible or could it be a substantial performance improvement on a
busy system?
We very rarely have deadlocks and waiting 30 seconds to discover one
doesn't seem too bad.

Thank you.

[PERFORM] pg_buffercache

[pg noob]

Hi all,

I was wondering if it is safe to install pg_buffercache on production
systems?

Thank you.

[PERFORM] query plan estimate

[pg noob]

Hi all,

I'm looking at this query plan, an excerpt of which is shown here, and I am
just wondering how the estimated cost for the Nested Loop is calculated?

->  Nested Loop  (*cost=0.00..2888.16* rows=240 width=16) (actual
time=0.034..2.180 rows=91 loops=1)
  Output: public.mg.lctime, public.mg.gfid
  ->  Index Scan using _
ba6cf7271af37e26c0e09e3225369f1b on version  (*cost=0.00..958.13* rows=240
width=8) (actual time=0.013..0.318 rows=91 loops=1)
Output: version.id, version.gfid, version.tid, version.seq,
version.txsid, version.objectid
  ->  Index Scan using mgfid__uniq on mg  (*cost=0.00..8.03* rows=1
width=16) (actual time=0.005..0.008 rows=1 loops=91)
Output: public.mg.id, public.mg.gfid, public.mg.ftype,
public.mg.lctime
Index Cond: (public.mg.gfid = version.gfid)
Filter: (public.mg.lctime < 1363076849)

What I expected is that it would be the sum of the output cost of the two
index scans?
I have no clue how it came up with 2,888.

Thank you.