ripts.
--
Regards Flemming Frandsen - YAPH - http://dion.swamp.dk
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ation?
--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH
---(end of broadcast)---
TIP 6: explain analyze is your friend
, I'm guessing
this is because a new transaction is started, is there any way to
improve performance of that?
Alvaro Herrera wrote:
> Do you regularly vacuum the pg_listener table?
No, but this is on a system that has been running for a couple of days.
--
Regards Flemming Frandse
FO: "pg_listener": removed 1207 row versions in 17 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pg_listener": found 1207 removable, 108 nonremovable row
versions in 3290 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 242413
iow. requests that took 500ms before are now down to around 25ms.
I will now hang my head in shame, please forgive me.
--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
cleanup thread
vacuums pg_listener (and some other tables) every 10 minutes.
Damnit, I thought I was kidding:)
--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH
---(end of broadcast)---
TIP 4: Have you searched our list archiv
ns are stored until all connections with earlier
started transactions have started new transactions.
This way we could even have wildcard listens, imagine doing a listen %
and getting all the generated events:)
--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH
-
the end of the transaction in
stead of the start of the transaction.
--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
all.
The listen should simply listen for events issued at the start of the
transaction it's executed in.
To do that without timetravel we'd need to store all events from all
transactions, but that's not too bad if it's implemented right.
--
Regards Flemming Frandse
nts that happen after the start of the transaction
have to be returned in the next transaction.
--
Regards Flemming Frandsen - http://dion.swamp.dk - YAPH
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropria
On 2 Aug 2006, Harald Fuchs wrote:
> > all events that have happened after the snapshot that the transaction
> > represents (the start of the transaction).
>
> Here you're contradicting yourself. In your second paragraph you
> state that LISTEN should get events unless later cancelled by a
> ROLL
On Wed, 2 Aug 2006, Tom Lane wrote:
> Flemming Frandsen <[EMAIL PROTECTED]> writes:
> > The listen should simply listen for events issued at the start of the
> > transaction it's executed in.
>
> BEGIN;
> SELECT sleep(10);
> LISTEN f
On Wed, 2 Aug 2006, Roman Neuhauser wrote:
> > I'm bothered by listen listening from the end of the transaction in
> > stead of the start of the transaction.
>
> Sorry if this isn't what you're after, instead just a question:
>
> Why don't you issue the LISTEN in a separate transaction bef
On Thu, 3 Aug 2006, Martijn van Oosterhout wrote:
> > There is no reason to assume that there would be any overhead in storing a
> > list of outstanding events for your connection compared to today.
>
> Err, yes there would. Think about it: for that example to work, the
> server would have to stor
On Fri, 4 Aug 2006, Martijn van Oosterhout wrote:
> Really? Even pg_dump cares? Or your maintainence scripts
> (VACUUM/ANALYZE)?
Ok, those clients don't, but you rarely have many vacuum/pg_dump
processes going on at the same time, so storing the events for them and
throwing them away is not that
15 matches
Mail list logo
