On Fri, Jul 7, 2017 at 5:17 AM, Robert Haas <robertmh...@gmail.com> wrote: > How is that possible? In a Zipfian distribution, no matter how big > the table is, almost all of the updates will be concentrated on a > handful of rows - and updates to any given row are necessarily > serialized, or so I would think. Maybe MongoDB can be fast there > since there are no transactions, so it can just lock the row slam in > the new value and unlock the row, all (I suppose) without writing WAL > or doing anything hard.
If you're not using the Wired Tiger storage engine, than the locking is at the document level, which means that a Zipfian distribution is no worse than any other as far as lock contention goes. That's one possible explanation. Another is that indexed organized tables naturally have much better locality, which matters at every level of the memory hierarchy. > I'm more curious about why we're performing badly than I am about a > general-purpose random_zipfian function. :-) I'm interested in both. I think that a random_zipfian function would be quite helpful for modeling certain kinds of performance problems, like CPU cache misses incurred at the page level. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
