From: | Kenny Bachman <kenny(dot)bachman17(at)gmail(dot)com> |
---|---|
To: | Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Postgresql 14 performance |
Date: | 2022-08-22 13:17:02 |
Message-ID: | CAC0w7L+GFza2xyAt-4SQwsMbQWAUqCf7tp+k5gOQZ6hwknDh3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
The huge_pages parameter is try. How can I know the huge page is used for
shared buffers?
Also, I would like to say one more thing. Some queries have high planning
time of explain analyze output. However, I run vacuumdb analyze command
every day. I am a little bit confused about this.
Warm regards,
Kenn
Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, 22 Ağu 2022 Pzt, 15:56 tarihinde
şunu yazdı:
> On 8/21/22 21:16, Mladen Gogala wrote:
>
> Agreed. The "perf top" output produced by Kenny definitely indicates that.
> That's precisely why I concentrated on JIT. Anything else would give us a
> slim chance of increasing the query speed.
>
> When I come to think of it, are you using huge pages for shared buffers?
> Huge pages tend to decrease page tables and lessen the impact of paging.
>
> Regards
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217https://dbwhisperer.wordpress.com
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sbob | 2022-08-22 16:20:41 | DB Encoding question |
Previous Message | Mladen Gogala | 2022-08-22 12:55:51 | Re: Postgresql 14 performance |