On 2015-04-20 01:04:18 -0700, Jeff Janes wrote: > Was this reproducible?
Yes, at least with an old version of the patch. I don't think you could see a difference using exactly that with the newer versions which have the 5 page limit. After all it'll pretty much never reach it. > > That's not a unrealistic testcase. > > > > I'm pretty sure this could be made quite a bit more pronounced by not > > using a uniform distribution in the pgbench runs. And selecting a test > > that's more vulnerable to the change (e.g. using a wider distribution > > for the read only statements than the modifying ones) would make the the > > CPU overhead of the additional heap_hot_search_buffer() overhead > > heavier. > > Sorry I don't understand this description. Why would queries selecting > data that is not changing have any extra overhead? The idea, I think, was that by having a uniform (or just wider) distribution of the reads they'd be more likely to land on values that have been updated at some point, but not been pruned since (because at that point the patch IIRC didn't prune during reads at all). I.e. ones wer > Is the idea that the hot part of the table for updates would move around > over time, but the hot part for selects would be even throughout? Pretty much. > I'm not sure how to put that to the test. That pretty much was what I'd tried to model, yea. I guess it'd be possible to model this by inserting NOW()/updating values NOW() - 5 and selecting values up to NOW() - 60. That'd roughly model some realistic insert/update/select patterns I've seen. To possibly see any difference with the new patch this would have to be done in a way that regularly a couple of pages would be touched, with not that many selected tuples on each. 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
