I noticed a minor omission in the patch as committed. Attached patch
corrects this.
--
Peter Geoghegan
*** a/contrib/pg_stat_statements/pg_stat_statements.c
--- b/contrib/pg_stat_statements/pg_stat_statements.c
*** generate_normalized_query(pgssJumbleStat
*** 2726,2732
if
Peter Geoghegan p...@heroku.com writes:
I noticed a minor omission in the patch as committed. Attached patch
corrects this.
Duh. Thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Geoghegan p...@heroku.com writes:
On Sun, Jan 26, 2014 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. This line of argument seems to reduce to we don't need to worry
about performance of this code path because it won't be reached often.
I think I may have over-elaborated, giving
On Mon, Jan 27, 2014 at 12:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
OK. Committed after a couple of small further revisions.
Great. Thank you.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Geoghegan p...@heroku.com writes:
On Sat, Jan 25, 2014 at 2:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it's fairly expensive to generate that text, in the case of a
large/complex statement. It's possible that continuing to hold the lock
is nonetheless the right thing to do because
On Sun, Jan 26, 2014 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. This line of argument seems to reduce to we don't need to worry
about performance of this code path because it won't be reached often.
I think I may have over-elaborated, giving you the false impression
that this was
Peter Geoghegan p...@heroku.com writes:
On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, have you got any sort of test scenario you could share for this
purpose? I'm sure I could build something, but if you've already
done it ...
I simply ran the standard regression
On Sat, Jan 25, 2014 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Do the regression tests fail for you when doing this?
What I see is a duplicate occurrence of an escape_string_warning bleat:
*** /home/postgres/pgsql/src/test/regress/expected/plpgsql.out Fri Jan 3
17:07
:46 2014
---
On Sat, Jan 25, 2014 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've chosen to handle failures to load query
text data by just returning NULL for that query text, which seems
reasonable given the new mindset that the query text is auxiliary data
less important than the actual counts.
I
Why do you think it's better to release the shared lock while
generating a normalized query text, only to acquire it once more? I'm
not suggesting that it's the wrong thing to do. I'm curious about the
reasoning around assessing the costs.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing
Peter Geoghegan p...@heroku.com writes:
Why do you think it's better to release the shared lock while
generating a normalized query text, only to acquire it once more? I'm
not suggesting that it's the wrong thing to do. I'm curious about the
reasoning around assessing the costs.
Well, it's
On Sat, Jan 25, 2014 at 2:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it's fairly expensive to generate that text, in the case of a
large/complex statement. It's possible that continuing to hold the lock
is nonetheless the right thing to do because release+reacquire is also
expensive; but
On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan p...@heroku.com wrote:
Actually, I think the whole thing is rather badly designed, as warm
cache or no you're still proposing to do thousands of kernel calls
while holding a potentially contended LWLock. I suggest what we
do is (1) read in the
On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan p...@heroku.com wrote:
BTW shouldn't there be an fflush() in qtext_store?
I don't think so, no. Whenever qtext_store() callers don't fflush()
before releasing their exclusive lock, they FreeFile() before doing so
instead. In the case of
Peter Geoghegan p...@heroku.com writes:
On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan p...@heroku.com wrote:
Actually, I think the whole thing is rather badly designed, as warm
cache or no you're still proposing to do thousands of kernel calls
while holding a potentially contended LWLock.
Peter Geoghegan p...@heroku.com writes:
I ran an strace on a pg_stat_statements backend with a full ~5,000
entries.
BTW, have you got any sort of test scenario you could share for this
purpose? I'm sure I could build something, but if you've already
done it ...
On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, have you got any sort of test scenario you could share for this
purpose? I'm sure I could build something, but if you've already
done it ...
I simply ran the standard regression tests, and then straced a backend
as it
Peter Geoghegan p...@heroku.com writes:
On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, have you got any sort of test scenario you could share for this
purpose? I'm sure I could build something, but if you've already
done it ...
I simply ran the standard regression
On Wed, Jan 22, 2014 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm, are there 5K distinct queries in the regression tests? I'd have
thought they weren't enough to fill a large pgss hash.
Well, yes. They're a really bad case for pg_stat_statements, in that
almost all distinct queries are
BTW, what is the value of using posix_fadvise() in warm_fcache?
ISTM that if you're worried about waiting for I/O while holding the
LWLock (as I concur you should be), this coding is entirely inadequate
for preventing that, as the whole point of posix_fadvise is that it
won't wait around for the
On Tue, Jan 21, 2014 at 6:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, what is the value of using posix_fadvise() in warm_fcache?
ISTM that if you're worried about waiting for I/O while holding the
LWLock (as I concur you should be), this coding is entirely inadequate
for preventing that,
On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan p...@heroku.com wrote:
Not necessarily. Under Linux for example, POSIX_FADV_SEQUENTIAL sets
the readahead window to the default size for the backing device
Excuse me; I meant to put POSIX_FADV_SEQUENTIAL doubles this size
[default size for the
Peter Geoghegan p...@heroku.com writes:
On Sat, Dec 7, 2013 at 9:26 AM, Fujii Masao masao.fu...@gmail.com wrote:
The patch doesn't apply cleanly against the master due to recent change of
pg_stat_statements. Could you update the patch?
Revision is attached, including changes recently
On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see this is marked as ready for committer. Where does it stand in
relation to the other long-running thread about calls under-estimation
propagation? I was surprised to find that there isn't any CommitFest
entry linked to
Peter Geoghegan p...@heroku.com writes:
On Mon, Jan 20, 2014 at 12:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I'm also thinking that the detected_version kluge is about ready
to collapse of its own weight, or at least is clearly going to break in
future. What we need to do is embed the
On Sat, Dec 7, 2013 at 9:26 AM, Fujii Masao masao.fu...@gmail.com wrote:
The patch doesn't apply cleanly against the master due to recent change of
pg_stat_statements. Could you update the patch?
Revision is attached, including changes recently discussed on other
thread [1] to allow avoiding
On Mon, Dec 9, 2013 at 7:31 PM, Peter Geoghegan p...@heroku.com wrote:
I go to some lengths to to avoid doing this with only a shared lock.
I should have said: I go to great lengths to do this with only a
shared lock, and not an exclusive (see gc_count stuff).
--
Peter Geoghegan
--
Sent
On Sun, Nov 17, 2013 at 1:15 PM, Peter Geoghegan p...@heroku.com wrote:
On Sat, Nov 16, 2013 at 4:36 PM, Peter Geoghegan p...@heroku.com wrote:
I'll post a revision with fixes for those. Another concern is that I
see some race conditions that only occur when pg_stat_statements cache
is under a
With a pg_stat_statements.max of 1,000, on my system with the patch
applied the additional amount of shared memory required is only
192KiB. That compares with about 1.17MiB for the same setting in
master's version of pg_stat_statements. Surely with this huge
reduction, we should revisit that
On Fri, Nov 15, 2013 at 8:51 AM, Peter Eisentraut pete...@gmx.net wrote:
Compiler warnings with fortify settings:
I'll post a revision with fixes for those. Another concern is that I
see some race conditions that only occur when pg_stat_statements cache
is under a lot of pressure with a lot of
On Sat, Nov 16, 2013 at 4:36 PM, Peter Geoghegan p...@heroku.com wrote:
I'll post a revision with fixes for those. Another concern is that I
see some race conditions that only occur when pg_stat_statements cache
is under a lot of pressure with a lot of concurrency, that wasn't
revealed by my
On 11/14/13, 3:17 AM, Peter Geoghegan wrote:
Attached patch allows pg_stat_statements to store arbitrarily long
query texts, using an external, transparently managed lookaside file.
Compiler warnings with fortify settings:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
32 matches
Mail list logo
