Dear PostgreSQL community,
we have noticed a severe decrease in performance reading
pg_catalog.pg_settings table in PostgreSQL 12 on MS Windows 10 machines
compared to earlier versions.
```
explain (analyze, buffers, timing)
SELECT * from pg_catalog.pg_settings where name =
Em sex., 8 de out. de 2021 às 04:01, Julius Tuskenis <
julius.tuske...@gmail.com> escreveu:
> Dear PostgreSQL community,
>
> we have noticed a severe decrease in performance reading
> pg_catalog.pg_settings table in PostgreSQL 12 on MS Windows 10 machines
> compared to earlier versions.
>
> ```
>
Thank you, Ranier,
v12.8 has improved the performance
PostgreSQL 12.8, compiled by Visual C++ build 1914, 64-bit:
```
Function Scan on pg_show_all_settings a (cost=0.00..12.50 rows=5
width=485) (actual time=7.122..7.128 rows=1 loops=1)
Filter: (name = 'standard_conforming_strings'::text)
Em sex., 8 de out. de 2021 às 09:06, Julius Tuskenis <
julius.tuske...@gmail.com> escreveu:
> Thank you, Ranier,
>
> v12.8 has improved the performance
>
> PostgreSQL 12.8, compiled by Visual C++ build 1914, 64-bit:
> ```
> Function Scan on pg_show_all_settings a (cost=0.00..12.50 rows=5
>
On 10/8/21 11:21, Bruce Momjian wrote:
Ah, this is exactly what I wanted to know --- what people are using the
event waits for. Can you tell if these are done all externally, or if
they need internal database changes?
Well, the methodology goes like this: we get the slow queries from
On Thu, Oct 7, 2021 at 10:22:12PM -0700, Jeremy Schneider wrote:
>
> On Oct 7, 2021, at 19:38, Bruce Momjian wrote:
> > Our wait events reported in pg_stat_activity are really only a first
> > step --- I always felt it needed an external tool to efficiently
> > collect and report those wait
On Thu, Oct 7, 2021 at 11:35:16PM -0400, Mladen Gogala wrote:
>
> On 10/7/21 22:15, Jeremy Schneider wrote:
> There is an extension which does wait event sampling:
>
> https://github.com/postgrespro/pg_wait_sampling
>
> It's one of the Postgres Pro extensions, I like it a lot. Postgres Pro is
Bruce Momjian schrieb am 08.10.2021 um 17:40:
I guess everyone will use that information in a different way.
We typically use the AWR reports as a post-mortem analysis tool if
something goes wrong in our application (=customer specific projects)
E.g. if there was a slowdown "last monday" or
On Fri, Oct 8, 2021 at 05:28:37PM +0200, Thomas Kellerer wrote:
> Bruce Momjian schrieb am 08.10.2021 um 17:21:
> > However, I also need to ask how the wait event information, whether
> > tracing or sampling, can be useful for Postgres because that will drive
> > the solution.
>
> I guess
> The history is long, but if you want to read.
>
https://www.postgresql.org/message-id/flat/7ff352d4-4879-5181-eb89-8a2046f928e6%40dunslane.net
Thank you, Ranier.
It's amazing how much effort and work that issue caused! Thank You and all
involved!
Regards,
Julius Tuskenis
2021-10-08, pn,
Bruce Momjian schrieb am 08.10.2021 um 17:21:
However, I also need to ask how the wait event information, whether
tracing or sampling, can be useful for Postgres because that will drive
the solution.
I guess everyone will use that information in a different way.
We typically use the AWR
On Fri, Oct 8, 2021 at 11:40 PM Bruce Momjian wrote:
>
> On Fri, Oct 8, 2021 at 05:28:37PM +0200, Thomas Kellerer wrote:
> >
> > We typically use the AWR reports as a post-mortem analysis tool if
> > something goes wrong in our application (=customer specific projects)
> >
> > E.g. if there was
12 matches
Mail list logo
