From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alik Khilazhev <a(dot)khilazhev(at)postgrespro(dot)ru> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] Zipfian distribution in pgbench |
Date: | 2017-07-13 20:13:42 |
Message-ID: | CAH2-WzkpVgkqQFqWYm9qhQucw3EN_dguwjbYRf4xZnJG1HV86w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 13, 2017 at 12:49 PM, Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-07-13 20:41:41 | Re: CAST vs :: |
Previous Message | Heikki Linnakangas | 2017-07-13 20:07:35 | Re: PostgreSQL - Weak DH group |