On Fri, Nov 18, 2022 at 8:20 PM Masahiko Sawada <
sawada.mshk@gmail.com> wrote:
>
> FYI I've not tested the patch you shared today but here are the
> benchmark results I did with the v9 patch in my environment (I used
> the second filter). I splitted 0004 patch into two patches: a patch
> for pure refactoring patch to introduce rt_node_ptr and a patch to do
> pointer tagging.
>
> v9 0003 patch : 1113 1114 1114
> introduce rt_node_ptr: 1127 1128 1128
> pointer tagging : 1085 1087 1086 (equivalent to 0004 patch)
>
> In my environment, rt_node_ptr seemed to lead some overhead but
> pointer tagging had performance benefits. I'm not sure the reason why
> the results are different from yours. The radix tree stats shows the
> same as your tests.
There is less than 2% difference from the medial set of results, so it's hard to distinguish from noise. I did a fresh rebuild and retested with the same results: about 15% slowdown in v9 0004. That's strange.
On Wed, Nov 16, 2022 at 10:24 PM Masahiko Sawada <
sawada.mshk@gmail.com> wrote:
> > filter = (((uint64) 1<<32) | (0xFF<<24));
> > LOG: num_keys = 9999944, height = 7, n4 = 47515559, n32 = 6209, n128 = 62632, n256 = 3161
> >
> > 1) Any idea why the tree height would be reported as 7 here? I didn't expect that.
>
> In my environment, (0xFF<<24) is 0xFFFFFFFFFF000000, not 0xFF000000.
> It seems the filter should be (((uint64) 1<<32) | ((uint64)
> 0xFF<<24)).
Ugh, sign extension, brain fade on my part. Thanks, I'm glad there was a straightforward explanation.
--
John Naylor
EDB:
http://www.enterprisedb.com
