On Wed, 2019-04-03 at 23:20 +, Raymond Martin wrote:
> Hi Christoph,
>
> > you sent the patch as UTF-16, could you re-send it as plain ascii?
>
> Apologies. I re-attached the plain ascii version.
Committed. Thanks!
Regards,
Jeff Davis
Hello Raymond,
Sure, it definitely makes sense to reduce the overhead when the extension is
disabled. I wanted to understand the source of performance issue, and your
explanations where not enough for reproducing it.
Thanks again Fabien. I am attaching the patch to this email in the hope of
Hi,
Apologies, but I had already created a commit here:
https://commitfest.postgresql.org/23/2080/ .
Any preference on which to keep?
Thanks,
Raymond Martin
rama...@microsoft.com
CF entry created
https://commitfest.postgresql.org/23/2092/
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
From: Robert Haas
>>
>> One thing that needs some thought here is what happens if the value of
>> pgss_enabled() changes. For example we don't want a situation where
>> if the value changes from off to on between one stage of processing
>> and another, the server crashes.
>>
>> I don't know wh
Hi Christoph,
> you sent the patch as UTF-16, could you re-send it as plain ascii?
Apologies. I re-attached the plain ascii version.
--
Raymond Martin
rama...@microsoft.com
Azure Database for PostgreSQL
check_pgss_enabled.patch
Description: check_pgss_enabled.patch
Robert Haas wrote
> On Tue, Apr 2, 2019 at 5:37 AM Christoph Berg <
> myon@
> > wrote:
>> Re: Raymond Martin 2019-04-01 <
> BN8PR21MB121708579A3782866DF1F745B1550@.outlook
> >
>> > Thanks again Fabien. I am attaching the patch to this email in the hope
>> of getting it approved during the next
On Tue, Apr 2, 2019 at 5:37 AM Christoph Berg wrote:
> Re: Raymond Martin 2019-04-01
>
> > Thanks again Fabien. I am attaching the patch to this email in the hope of
> > getting it approved during the next commit fest.
>
> you sent the patch as UTF-16, could you re-send it as plain ascii?
One
Re: Raymond Martin 2019-04-01
> Thanks again Fabien. I am attaching the patch to this email in the hope of
> getting it approved during the next commit fest.
Raymond,
you sent the patch as UTF-16, could you re-send it as plain ascii?
Christoph
Hi,
it seems that your patch is not readable.
If you want it to be included in a commitfest, you should add it by yourself
in https://commitfest.postgresql.org/
Not sure that there is any room left in pg12 commitfest.
Regard
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-ha
Hi Fabien,
> Sure, it definitely makes sense to reduce the overhead when the extension is
> disabled. I wanted to understand the source of performance issue, and your
> explanations where not enough for reproducing it.
Thanks again Fabien. I am attaching the patch to this email in the hope of
Hello Raymond,
Note that this does not mean that the patch should not be applied, it
looks like an oversight, but really I do not have the performance
degradation you are suggesting.
I appreciate your input and I want to come up with a canonical test that
makes this contention more obvious
my test case:
drop table a;
create table a ();
DO
$$
DECLARE
i int;
BEGIN
for i in 1..20
loop
execute 'alter table a add column a'||i::text||' int';
end loop;
END
$$;
select pg_stat_statements_reset();
set pg_stat_statements.track='none';
DO
$$
DECLARE
i int;
j int;
BEGIN
for j in 1..20
loop
f
Hi Fabien,
Thank you for your time. Apologies for not being more specific about my testing
methodology.
> > PGSS not loaded: 0.18ms
>
> This means 0.0018 ms latency per transaction, which seems rather fast, on my
> laptop I have typically 0.0XX ms...
This actually means 0.18 milliseconds. I ag
Your fix is probably the best one.
Maybe this could be considered as a bug and back ported to previous versions
...
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
Hi Pascal,
Thanks for your feedback! I like your ideas.
>the part that hurts in terms or performances is:
>
> if (jstate.clocations_count > 0)
> pgss_store(pstate->p_sourcetext,
I agree that this is the typically the most expensive part, but query
normalization and hashing c
Hi,
the part that hurts in terms or performances is:
if (jstate.clocations_count > 0)
pgss_store(pstate->p_sourcetext,
query->queryId,
query->stmt_location,
query->stmt_len,
Hello Raymond,
Would it make sense to check for pgss_enabled in the post_parse_analyze_hook
function?
Probably.
- /* Safety check... */
- if (!pgss || !pgss_hash)
+ /* Safety check...and ensure that pgss is enabled before we do any work
*/
+ if (!pgss || !pgss_hash
Hello hackers,
This email is regarding the Postgres pg_stat_statements extension.
I noticed that enabling pg_stat_statements can effect performance. I thought
that changing the pg_stat_statements.track parameter to 'none' could reduce
this overhead without requiring a restart to remove it from
19 matches
Mail list logo
