| From: | Denis Smirnov <sd(at)arenadata(dot)io> |
|---|---|
| To: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PoC Refactor AM analyse API |
| Date: | 2021-02-19 07:59:25 |
| Message-ID: | 29A6A06B-7CE8-4460-AA1F-33DB6709F6BD@arenadata.io |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello, Zhihong.
Thanks for your comments.
1. I am afraid that an equivalence of "floor(val + 0.5)" to "cell(val)" is incorrect: "floor(2.1 + 0.5)" returns 2 while "cell(2.1)" returns 3. We can’t use such replacement, as you have suggested.
2. >> For compare_rows(), it seems the computation of oa and ob can be delayed to when ba == bb (after the first two if statements).
I have checked some examples of ASM code generated by different compilers with -O2/O3 flags on https://gcc.godbolt.org and didn’t see any big benefit in result CPU instructions. You can check yourself an attached example below.
| Attachment | Content-Type | Size |
|---|---|---|
| simplified_compare_rows.c | application/octet-stream | 611 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2021-02-19 08:03:41 | Re: a misbehavior of partition row movement (?) |
| Previous Message | Pavel Stehule | 2021-02-19 07:47:19 | Re: Problem with accessing TOAST data in stored procedures |