From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: memory layouts for binary search in nbtree |
Date: | 2017-06-27 18:17:29 |
Message-ID: | CAH2-WzmkQtyzBQdP6=mCRj98rEF2AfmxrXp9DRdccfiUt+L0qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 27, 2017 at 11:05 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Did you ever try running a pgbench SELECT benchmark, having modified
>> things such that all PKs are on columns that are not of type
>> int4/int8, but rather are of type numeric? It's an interesting
>> experiment, that I've been meaning to re-run on a big box.
>
>> Obviously this will be slower than an equivalent plain pgbench SELECT,
>> but the difference may be smaller than you expect.
>
> I'm not sure what that has to do with the topic?
It suggests that cache misses are much more important than anything
else. Even with collated text, the difference is not so large IIRC.
Though, it was noticeably larger.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-06-27 18:44:06 | Re: Fast promotion not used when doing a recovery_target PITR restore? |
Previous Message | Peter Geoghegan | 2017-06-27 18:13:38 | Re: memory layouts for binary search in nbtree |