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

help / color / mirror / Atom feed
From: 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, 04 Oct 2015 18:10:23 -0400
Message-ID: <30253.1443996623@sss.pgh.pa.us> (raw)
In-Reply-To: <CAM3SWZRYvummSEJiNzJEnLqp5T6_66wAF5Sj32AivPAa5kVJSA@mail.gmail.com>
References: <5601D354.5000703@BlueTreble.com>
	<CAM3SWZRo_5ZznTp=Mg5Kh2eq-LjWLVS-BXJwsHe_dS50g34Mfw@mail.gmail.com>
	<15898.1442965225@sss.pgh.pa.us>
	<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Peter Geoghegan <pg@heroku.com> writes:
> On Sun, Oct 4, 2015 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm.  The problem I've got with this is that then mean_query_len means
>> something significantly different after entry_dealloc than it does
>> after gc_texts.
>> 
>> I'd be okay with changing *both* of those functions to ignore sticky
>> entries in the calculation, if that seems reasonable to you.

> That seems perfectly reasonable, yes. Should I leave that to you?

After a closer look I decided that wasn't reasonable at all.  Discounting
sticky texts would then mean that after a GC cycle, we might still think
the query texts file is bloated and issue another GC request, which of
course would not shrink the file, so that we'd be doing GC cycles every
time we added a new query.  The mean query len recorded by gc_qtexts()
*has to* match the mean length of what it actually put in the file, not
the mean length of what we might wish it would put in the file.

By the same token, I'm back to believing that it's fundamentally bogus for
entry_dealloc() to compute mean_query_len that way.  The most likely
result of that is useless GC cycles.  The only thing that will actually
free memory when you've got a lot of dead sticky entries is getting rid of
the sticky hashtable entries, and the only way to do that is to wait for
entry_dealloc() to get rid of 'em.  You were unenthused about making that
removal more aggressive, which is fine, but you can't have it both ways.

It does strike me that when we do get rid of the sticky entries, cleanup
of the texts file might lag a bit longer than it needs to because
mean_query_len is computed before not after deleting whatever entries
we're going to delete.  On average, that shouldn't matter ... but if we
are tossing a bunch of dead sticky entries, maybe they would have a higher
mean length than the rest?  Not sure about it.  I put a comment about
this into entry_dealloc() for the moment, but we can revisit whether it
is worth adding code/cycles to get a more up-to-date mean length.

Anyway, I've committed the aspects of this that we're agreed on.

			regards, tom lane


-- 
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: <30253.1443996623@sss.pgh.pa.us>
Permalink:  ../30253.1443996623@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/30253.1443996623@sss.pgh.pa.us

 · 

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: 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: <30253.1443996623@sss.pgh.pa.us>

* 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