| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Yet another fast GiST build |
| Date: | 2019-08-29 23:33:48 |
| Message-ID: | CAH2-WzkEFK6=oDMB8qWO5AepcSPRuvs__0Mh=x9z2u5ocK0VcA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 29, 2019 at 3:48 PM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > As you can see, Z-order build is on order of magnitude faster. Select performance is roughly the same. Also, index is significantly smaller.
>
> Cool! These experiments bring me to following thoughts. Can we not
> only build, but also maintain GiST indexes in B-tree-like manner? If
> we put Z-value together with MBR to the non-leaf keys, that should be
> possible. Maintaining it in B-tree-like manner would have a lot of
> advantages.
I'm not an expert on GiST, but that seems like it would have a lot of
advantages in the long term. It is certainly theoretically appealing.
Could this make it easier to use merge join with containment
operators? I'm thinking of things like geospatial joins, which can
generally only be performed as nested loop joins at the moment. This
is often wildly inefficient.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-08-30 00:07:53 | Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. |
| Previous Message | Alexander Korotkov | 2019-08-29 22:47:49 | Re: Yet another fast GiST build |