On Fri, 8 Nov 2024 at 10:54, Ed Sabol <edwardjsabol@gmail.com> wrote:
> The good news is that, after some research and experimentation, I was able to fix this performance degradation by
settingrandom_page_cost = 2.0. We've always used the default values for seq_page_cost and random_page_cost (1.0 and
4.0,respectively, I think?). A lot of the advice I found online suggested these *_page_cost settings are too high?
Often people lower random_page_cost when running SSDs. The default
value of 4.0 was determined before SSDs were a thing.
> Did upgrading PostgreSQL to 15.8 cause this performance degradation? Did the page costs calculation change in 15.8
(or15.7)? The PostgreSQL version is the only thing that has appreciably changed with this database this whole year.
It's impossible to say with the given information. You didn't mention
which version you upgraded from to start with.
We'd need to see EXPLAIN ANALYZE from before and after you changed
random_page_cost.
> Or do you think the size of the table just incrementally reached some threshold that resulted in the optimizer
changingits plan based on the page costs?
It's possible, but it's also impossible to know without having more information.
> All of the columns are text fields and indexed. Unfortunately, I don't have the "EXPLAIN (ANALYZE, BUFFERS)" output
frombefore I changed the random_page_cost setting. It's no longer in my scollback buffer.
You can set random_page_cost for just the session you're connected to
and try it. SET random_page_cost = <old value>; before running
EXPLAIN (ANALYZE, BUFFERS).
David
