On Tue, Dec 3, 2019 at 11:46 AM Sachin Divekar wrote:
> I am also going to use SKIP LOCKED to _select for update_. Any suggestions
> on tuning parameters for SKIP LOCKED?
>
I am not aware of any. Either you use it because it fits your need, or not.
Note- please don't top-post (reply and include
Thank you, Michaels.
.
I didn't know about fillfactor and table bloat. Did some reading on those
topics. We will definitely need to tweak these settings.
I am also going to use SKIP LOCKED to _select for update_. Any suggestions
on tuning parameters for SKIP LOCKED?
Thanks
On Tue, Dec 3, 2019 at
Yep, I concur completely! For tables treated like queues you gotta do
this stuff or deal with bloat and fragmented indexes.
Michael Lewis wrote on 12/3/2019 12:29 PM:
"I am going to use it as a queue"
You may want to look at lowering fillfactor if this queue is going to
have frequent updates
"I am going to use it as a queue"
You may want to look at lowering fillfactor if this queue is going to have
frequent updates, and also make autovacuum/analyze much more aggressive
assuming many updates and deletes.
All updated/dirty records go through PG internal memory buffer,
shared_buffers. Make sure that is configured optimally. Use
pg_buffercache extension to set it correctly.
Regards,
Michael Vitale
Hüseyin Demir wrote on 12/2/2019 12:13 PM:
I guess there won't be any adverse effect
Hi,
PostgreSQL decides which pages should be evicted from memory and written to
disk with the help of LRU algorithm. Thus, it depends on your query work
load. In OLTP systems, the algorithm is beneficial to business
requirements(almost :) )
It's hard to figure out that a configuration change will
Hi,
I am looking for tuning my PG setup such that recently inserted or updated
record will be available in the buffer/cache (I believe they are same in
this context). Does PostgreSQL do it by default? If yes, just increasing
buffer size sufficient? What will be its effect on LRU performance -- I
g
