From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | DAVID ROTH <adaptron(at)comcast(dot)net> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Multiple Indexes |
Date: | 2022-07-06 18:53:22 |
Message-ID: | CAApHDvq5V0XJzWSi=bUS+P76khegqbLVMkN8wPj6_c-Gkx6Xug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 7 Jul 2022 at 04:07, DAVID ROTH <adaptron(at)comcast(dot)net> wrote:
> I understand the planner can use multiple indexes to get the best plan.
> Can someone point me a paper that explains how this works.
I don't know of a paper, but if you're talking about using multiple
indexes to scan a single relation in order to satisfy a condition such
as; WHERE a = 5 OR b = 12; then the query planner is able to make use
of "bitmap index scans". A bitmap index scan simply scans an index
type which supports such scans and collects a set of ctids. For this
example, providing there's a suitable index on the "a" column and
another on the "b" column, the planner may choose to perform a bitmap
index scan on the "a" index and another on the "b" index then perform
a bitmap OR operation to obtain the intersecting ctids. The heap of
the table can then be scanned to fetch the intersecting ctids.
A ctid is the physical (more physiological) address of a tuple the
heap of a table.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2022-07-06 19:33:42 | Re: lifetime of the old CTID |
Previous Message | Bryn Llewellyn | 2022-07-06 18:50:26 | Re: Seems to be impossible to set a NULL search_path |