Catching up with performance & PostgreSQL 15

2022-11-28 Thread Josh Berkus

Hey, folks:

I haven't configured a PostgreSQL server since version 11 (before that, 
I did quite a few).


What's changed in terms of performance configuration since then?  Have 
the fundamentals of shared_buffers/work_mem/max_connections changed at 
all?  Which new settings are must-tunes?


I've heard about new parallel stuff an JIT, but neither is that 
applicable to my use-case.


--
Josh Berkus




Re: Catching up with performance & PostgreSQL 15

2022-11-28 Thread Justin Pryzby
On Mon, Nov 28, 2022 at 06:59:41PM -0800, Josh Berkus wrote:
> Hey, folks:
> 
> I haven't configured a PostgreSQL server since version 11 (before that, I
> did quite a few).
> 
> What's changed in terms of performance configuration since then?  Have the
> fundamentals of shared_buffers/work_mem/max_connections changed at all?
> Which new settings are must-tunes?
> 
> I've heard about new parallel stuff an JIT, but neither is that applicable
> to my use-case.

shared buffers is the same, but btree indexes are frequently (IME) 3x
smaller (!) since deduplication was added in v13, so s_b might not need
to be as large.

In addition to setting work_mem, you can also (since v13) set
hash_mem_multiplier.

default_toast_compression = lz4 # v14
recovery_init_sync_method = syncfs # v14
check_client_connection_interval = ... # v14
wal_compression = {lz4,zstd} # v15

Peeking at my notes, there's also: partitioning, parallel query, brin
indexes, extended statistics, reindex concurrently, ...

... but I don't think anything is radically changed :)

-- 
Justin




Re: Catching up with performance & PostgreSQL 15

2022-11-28 Thread Mladen Gogala

On 11/28/22 21:59, Josh Berkus wrote:

Hey, folks:

I haven't configured a PostgreSQL server since version 11 (before 
that, I did quite a few).


What's changed in terms of performance configuration since then? Have 
the fundamentals of shared_buffers/work_mem/max_connections changed at 
all?  Which new settings are must-tunes?


I've heard about new parallel stuff an JIT, but neither is that 
applicable to my use-case.


Well, well! Long time no see! You'll probably be glad to learn that we 
have hints now. Thank you for the following page you created:


https://laptrinhx.com/why-postgresql-doesn-t-have-query-hints-2912445911/

I've used it several times, with great success. It's priceless.

Now, to answer your question: no, fundamentals of shared buffers, work 
memory and connections haven't changed. Parallelism works fine, it's 
reliable and easy to enable. All you need is to set 
max_parallel_workers_per_gather to an integer > 0 and PgSQL 15 will 
automatically use parallel plan if the planner decides that it's the 
best path. However, to warn you in advance, parallel query is not a 
panacea. On OLTP databases, I usually disable it on purpose. Parallel 
query will speed up sequential scans, but if your application is OLTP, 
sequential scan is a sign of trouble. Parallelism is a data warehouse 
only feature. And even then, you don't want it ti be run by multiple 
users at the same time. Namely, the number of your CPU resources is 
finite and having multiple users launch multiple processes is the best 
way to run out of the CPU power fast. Normally, you would package an 
output of the parallel query into a materialized view and let the users 
query the view.


As for JIT, I've recently asked that question myself. I was told that 
PostgreSQL with LLVM enabled performs approximately 25% better than 
without it. I haven't measured it so I can't  either confirm or deny the 
number.  I can tell you that there is a noticeable throughput 
improvement with PL/PGSQL intensive applications. There was also an 
increase in CPU consumption. I wasn't doing benchmarks, I was looking 
for a generic settings to install via Ansible so I don't have the 
numbers, only the feeling. One way of quantifying the difference would 
be to run pgbench with and without JIT.


PS:

I am still an Oracle DBA, just as you wrote in the paper.

--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com


Re: Catching up with performance & PostgreSQL 15

2022-11-28 Thread Josh Berkus

On 11/28/22 19:34, Justin Pryzby wrote:

In addition to setting work_mem, you can also (since v13) set
hash_mem_multiplier.


Is there any guidance on setting this?  Or is it still "use the default 
unless you can play around with it"?



default_toast_compression = lz4 # v14
recovery_init_sync_method = syncfs # v14
check_client_connection_interval = ... # v14
wal_compression = {lz4,zstd} # v15


If anyone has links to blogs or other things that discuss the 
performance implications of the above settings that would be wonderful!


--
Josh Berkus