| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: hashjoins vs. Bloom filters (yet again) |
| Date: | 2026-08-19 19:25:02 |
| Message-ID: | aoYDDmuf1fqksOdz@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 19, 2026 at 07:31:18PM +0200, Tomas Vondra wrote:
> On 8/19/26 17:05, Bruce Momjian wrote:
> > One topic that came up in the Pittsburgh AI Workshop was the idea of
> > combining indexes. For example, right now, all indexes point to heap,
> > and we usually go from index to heap. We can combine indexes using
> > bitmap scans of heap tids. Would there be any value of improving our
> > ability to combine indexes beyond bitmap scans?
> >
>
> Are you describing something like this [1]? That is, ability to build a
> bitmap (from bitmap index scan), and pass it into an index scan, so that
> it can benefit from the selective bitmap filter and ordering of the
> regular index scan?
>
> I think that's an interesting idea / scan variant, skipping a possibly
> expensive Sort. But I don't quite see how is that related to the topic
> of this thread? It transfers predicate within a single scan (from one
> index to the other), while the hashjoin bloom pushdown "transfers"
> predicates between different plan nodes, possibly very distant.
Yeah, not sure what I am asking. It was just a thought that maybe more
flexible index combining can be helpful.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-08-19 19:32:48 | Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row |
| Previous Message | Bharath Rupireddy | 2026-08-19 18:44:00 | Re: Further cleanup related to statistics import support in postgres_fdw |