Hi, On 2016-04-12 14:17:12 -0500, Kevin Grittner wrote: > Well, something is different between your environment and mine, > since I saw no difference at scale 100 and 2.2% at scale 200.
In a readonly test or r/w? A lot of this will be different between single-socket and multi-socket servers; as soon as you have the latter the likelihood of contention being bad goes up dramatically. > So, > knowing more about your hardware, OS, configuration, etc., might > allow me to duplicate a problem so I can fix > For example, I used a "real" pg config, like I would for a production > machine (because that seems to me to be the environment that is most > important): the kernel is 3.13 (not one with pessimal scheduling) and > has tuning for THP, the deadline scheduler, the vm.*dirty* settings, > etc. Without knowing even the kernel and what tuning the OS and pg > have had on your box, I could take a lot of shots in the dark without > hitting anything. That shouldn't really matter much for a read-only, shared_buffer resident, test? There's no IO and THP pretty much plays no role because there's very few memory allocations (removing the pressure causing the well known degradations). > Oh, and the output of `numactl --hardware` would be good to have. > Thanks for all information you can provide. That was on Alexander's/PgPro's machine. Numactl wasn't installed, and I didn't have root. But it has four numa domains (gathered via /sys/). > It was the only reported case to that point, so the additional data > point is valuable, if I can tell where that point is. And you > don't have any evidence that even with your configuration that any > performance regression remains for those who have the default value > for old_snapshot_threshold? I haven't tested yet. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers