Re: [HACKERS] [WIP] Zipfian distribution in pgbench
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] [WIP] Zipfian distribution in pgbench |
Дата | |
Msg-id | CAH2-WzkpVgkqQFqWYm9qhQucw3EN_dguwjbYRf4xZnJG1HV86w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [WIP] Zipfian distribution in pgbench (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: [HACKERS] [WIP] Zipfian distribution in pgbench
|
Список | pgsql-hackers |
On Thu, Jul 13, 2017 at 12:49 PM, Peter Geoghegan <pg@bowt.ie> wrote: > To reiterate what I say above: > > The number of leaf pages with dead items is 20 with this most recent > run (128 clients, patched + unpatched). The leftmost internal page one > level up from the leaf level contains 289 items. Whereas last time it > was 353 items. > > That's a difference between having 20 hot/bloated leaf pages, and > probably 84 hot/bloated pages, which I infer must have been the total > number of bloated leaf pages within "result.txt". I think that > something about all the "pgbench_index_*txt" tests are very different > to what we see within "result.txt". It's as if there was a problem > when "result.txt" ran, but that problem somehow didn't come up when > you did new tests. I just figured out that "result.txt" is only a 60 second pgbench run. Is the same true for other tests? It would be much more interesting to see runs that lasted 10 minutes or more. Maybe with pgbench-tools. I would expect that a decline in performance due to bloating the index could happen only after a certain threshold was crossed. Things like HOT pruning and LP_DEAD cleanup could be pretty effective, until finally a tipping point is reached and they're much less effective. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: