| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Pluggable storage |
| Date: | 2017-06-23 14:24:59 |
| Message-ID: | 8786.1498227899@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> It would be really great if you could explain why BitmapScans are
> dubious, instead of just labeling them as dubious. (I guess you mean
> Bitmap Heap Scans, right?)
The two things I'm aware of are (a) the assumption you noted, that
fetching tuples in TID sort order is a reasonably efficient thing,
and (b) the "offset" part of a TID can't exceed MaxHeapTuplesPerPage
--- see data structure in tidbitmap.c. The latter issue means that
you don't really have a full six bytes to play with in a TID, only
about five.
I don't think (b) would be terribly hard to fix if we had a motivation to,
but I wonder whether there aren't other places that also know this about
TIDs.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2017-06-23 14:48:13 | Re: Broken hint bits (freeze) |
| Previous Message | Tom Lane | 2017-06-23 14:09:41 | Re: REPLICA IDENTITY FULL |