From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Is it useful to record whether plans are generic or custom? |
Date: | 2020-11-12 01:49:53 |
Message-ID: | 4ad1099133c09f4690ff212d3d4867de@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-09-29 02:39, legrand legrand wrote:
> Hi Atsushi,
>
> +1: Your proposal is a good answer for time based performance analysis
> (even if parsing durationor blks are not differentiated) .
>
> As it makes pgss number of columns wilder, may be an other solution
> would be to create a pg_stat_statements_xxx view with the same key
> as pgss (dbid,userid,queryid) and all thoses new counters.
Thanks for your ideas and sorry for my late reply.
It seems creating pg_stat_statements_xxx views both for generic and
custom plans is better than my PoC patch.
However, I also began to wonder how effective it would be to just
distinguish between generic and custom plans. Custom plans can
include all sorts of plans. and thinking cache validation, generic
plans can also include various plans.
Considering this, I'm starting to feel that it would be better to
not just keeping whether generic or cutom but the plan itself as
discussed in the below thread.
Any thoughts?
Regards,
--
Atsushi Torikoshi
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-11-12 02:00:14 | Re: Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS |
Previous Message | Fujii Masao | 2020-11-12 01:40:12 | Re: recovery_target immediate timestamp |