On Wed, Dec 14, 2022 at 12:03 PM Rick Otten wrote:
> Assuming I can live with the slower inserts, is there any parameter in
> particular I can tweak that would make the time it takes to create the hash
> index closer to the btree index creation time? In particular if I wanted to
> try this on
I inherited a database with several single-digit billion row tables. Those
tables have a varchar(36) column populated with uuids (all connected to
each other via FKs) each currently supported by a btree index.
After the recent conversations about hash indexes I thought I'd do some
comparisons to
Awesome, this is really helpful Samed. I'll start experimenting with these
settings next. Really appreciate your guidance.
On Wed, Dec 14, 2022 at 10:41 AM Samed YILDIRIM wrote:
> Hello Jordan,
>
> You don't have to set %25 for the best performance. You need to test
> different values for your d
Hello Jordan,
You don't have to set %25 for the best performance. You need to test
different values for your database. If I were you, I would
- try to enable huge pages. You probably will see better performance
with bigger shared_buffers when you configure huge pages. ->
https://www.post
Thanks Tom, that makes a lot of sense. Given we're seeing low iowait and
blk_read_time at 4GB shared_buffers, sounds like we should just declare
victory here and be happy with that setting?
On Wed, Dec 14, 2022 at 10:27 AM Tom Lane wrote:
> Jordan Hurwich writes:
> > I'm familiar with the artic
Jordan Hurwich writes:
> I'm familiar with the article you linked to, and part of my surprise is
> that with these 32GB RAM machines we're seeing better performance at 12.5%
> (4GB) than the commonly recommended 25% (8GB) of system memory for
> shared_buffers. Your notes about disk read stats from
Thanks for your thoughtful response Samed.
I'm familiar with the article you linked to, and part of my surprise is
that with these 32GB RAM machines we're seeing better performance at 12.5%
(4GB) than the commonly recommended 25% (8GB) of system memory for
shared_buffers. Your notes about disk rea
Hi Jordan,
Increased shared buffer size does not necessarily mean an increased
performance.
Regarding the negative correlation between IOWait and shared_buffers' size;
if you don't increase memory of the system, it is an expected result in my
opinion. Because, PostgreSQL starts reserving a bigger
