pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@heroku.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Less than ideal error reporting in pg_stat_statements
Date: Sun, 4 Oct 2015 18:58:41 -0400
Message-ID: <5611AF21.9090900@dunslane.net> (raw)
In-Reply-To: <30415.1443996994@sss.pgh.pa.us>
References: <5601D354.5000703@BlueTreble.com>
	<CAM3SWZT41NeiK74J4PeKBA=rkML6-TR1pmj_ABf7Y6c8ihR+4A@mail.gmail.com>
	<CAM3SWZTOjkP9EJsaUcvhpHxXfdCyXbCcFuTDNT4Qct90ZMU8Hw@mail.gmail.com>
	<CAM3SWZTJEPY7A5HBJMB-s6rhZxk8LXiaxZPAMDytBpLs3P60Tw@mail.gmail.com>
	<CAM3SWZQBf6nepv2PKm_PDqwxUzxgzp5664bmRpq4AhSTM2UX_w@mail.gmail.com>
	<5913.1443822154@sss.pgh.pa.us>
	<CAM3SWZQjp_W4bZC=BgEQrP3EXrEnOzaytkJZbntdmZe8f2EOBQ@mail.gmail.com>
	<CAM3SWZTahp86i-5vDnfL5nzYCUjdmRu=sWRKXEZVd3E9dKGEFA@mail.gmail.com>
	<CAM3SWZTwNKkeCN+n_ew2eLFrWT9+UcPRLUTyy_xWN12QzGORsA@mail.gmail.com>
	<9935.1443828452@sss.pgh.pa.us>
	<CAM3SWZTZfwJRBv85XHcbc-TRhM4xsOD6fYfU3anF9WVTNeRUFw@mail.gmail.com>
	<32385.1443976035@sss.pgh.pa.us>
	<CAM3SWZRH8=6P8=eicmOFAY+WROV_5giezZc=LnoUUtFYRYG0pg@mail.gmail.com>
	<26165.1443988873@sss.pgh.pa.us>
	<CAM3SWZRYvummSEJiNzJEnLqp5T6_66wAF5Sj32AivPAa5kVJSA@mail.gmail.com>
	<CAM3SWZQ2S7kDr9qaOms! EsotqPR0XU2Gzc8oavw_HvMpSkvPBPQ@mail.gmail.com>
	<30415.1443996994@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>



On 10/04/2015 06:16 PM, Tom Lane wrote:
> Peter Geoghegan <pg@heroku.com> writes:
>> To be clear: I wasn't sure why you though I falsely count entries with
>> dropped texts within entry_dealloc().
> In the existing^H^H^Hprevious code, dropped-text entries would essentially
> act as length-zero summands in the average calculation, whereas I think
> we agree that they ought to be ignored; otherwise they decrease the
> computed mean and thereby increase the probability of (useless) GC cycles.
> In the worst case where the hashtable is mostly dropped-text entries,
> which would for instance be the prevailing situation shortly after a GC
> failure, we'd be calculating ridiculously small mean values and that'd
> prompt extra GC cycles no?
>
> 			


Sorry, I'm a bit late to this party. Does what you have committed mean 
people are less likely to see "Out of Memory" coming from 
pg_stat_statements? If not, what can be done about them short of a 
restart? And what bad effects follow from an event generating them?

The docs seem to be quite silent on these points.

cheers

andrew


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



view thread (49+ messages)  latest in thread

Message-ID: <5611AF21.9090900@dunslane.net>
Permalink:  ../5611AF21.9090900@dunslane.net/
Also on:    postgresql.org/message-id/5611AF21.9090900@dunslane.net

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: andrew@dunslane.net, tgl@sss.pgh.pa.us, pg@heroku.com, Jim.Nasby@bluetreble.com
  Subject: Re: Less than ideal error reporting in pg_stat_statements
  In-Reply-To: <5611AF21.9090900@dunslane.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox