| From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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 08:38:57 |
| Message-ID: | 8b2510f0-ab89-dbf1-5b1c-5d686a5e33b8@sigaev.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 1. Table AM with a 6-byte TID.
> 2. Table AM with a custom locator format, which could be TID-like.
> 3. Table AM with no locators.
Currently TID has its own type in system catalog. Seems, it's possible that
storage claims type of TID which it uses. Then, AM could claim it too, so the
core based on that information could solve the question about AM-storage
compatibility. Storage could also claim that it hasn't TID type at all so it
couldn't be used with any access method, use case: compressed column oriented
storage.
As I remeber, only GIN depends on TID format, other indexes use it as opaque
type. Except, at least, btree and GiST - they believ that internal pointers are
the same as outer (to heap)
Another dubious part - BitmapScan.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-06-23 08:59:12 | Re: A bug in mapping attributes in ATExecAttachPartition() |
| Previous Message | Stas Kelvich | 2017-06-23 08:12:40 | Re: Dynamic instrumentation of lwlock wait times (lwlock flamegraphs) |