On Thu, Aug 10, 2017 at 11:12 AM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> These results look very cool!
> I think CSN is eventually inevitable, but it's a long distance feature.
> Thus, this optimization could make us a good serve before we would have CSN.
> Do you expect there are cases when this patch causes slowdown? What about
> case when we scan each xip array only once (not sure how to simulate that
> using pgbench)?
Just a random thought here:
The statements pgbench executes are pretty simple: they touch one row
in one table. You wouldn't expect them to scan the xip array very
many times. If even those statements touch the array enough for this
to win, it seems like it might be hard to construct an even worse
case. I might be missing something, though.
We're not going to accept code like this, though:
+ d = xip[i] >> 6;
+ j = k = xip[i] & mask;
+ while (xiphash[j] != InvalidTransactionId)
+ {
+ j = (k + d) & mask;
+ d = d*5 + 1;
+ }
Single-character variable names, hard-coded constants, and no comments!
I kind of doubt as a general point that we really want another
open-coded hash table -- I wonder if this could be made to use
simplehash.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
