| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: MDAM techniques and Index Skip Scan patch |
| Date: | 2022-03-29 00:21:54 |
| Message-ID: | 1055005.1648513314@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> We could get rid of dynamic allocations for BTStackData in
> _bt_first(), perhaps. The problem is that there is no simple,
> reasonable proof of the maximum height on a B-tree, even though a
> B-Tree with more than 7 or 8 levels seems extraordinarily unlikely.
Start with a few entries preallocated, and switch to dynamically
allocated space if there turn out to be more levels than that,
perhaps? Not sure if it's worth the trouble.
In any case, what I was on about is _bt_preprocess_keys() and
adjacent code. I'm surprised that those aren't more expensive
than one palloc in _bt_first. Maybe that logic falls through very
quickly in simple cases, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2022-03-29 00:48:50 | Re: POC: GROUP BY optimization |
| Previous Message | Tatsuo Ishii | 2022-03-29 00:19:44 | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |