| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Raymond Martin <ramarti(at)microsoft(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: minimizing pg_stat_statements performance overhead |
| Date: | 2019-03-28 06:07:22 |
| Message-ID: | alpine.DEB.2.21.1903280704380.4274@lancre |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. Unfortunately, it is difficult
> because the criteria that causes this slow down (large query sizes and
> distinct non-repeated queries) are difficult to reproduce with pgbench.
> I would be open to any suggestions here.
>
> So even though the performance gains in this specific scenario are not
> as great, do you still think it would make sense to submit a patch like
> this?
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.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haribabu Kommi | 2019-03-28 06:12:57 | Re: Transaction commits VS Transaction commits (with parallel) VS query mean time |
| Previous Message | Tsunakawa, Takayuki | 2019-03-28 06:01:43 | RE: Timeout parameters |