From: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactoring of heapam code. |
Date: | 2016-08-05 13:38:29 |
Message-ID: | 87f83470-0f54-ffa6-3635-51c0f44c8f72@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
05.08.2016 16:30, Kevin Grittner:
> On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova
> <a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
>
>> They can be logically separated into three categories:
>> "primary storage" - r, S, t, v. They store data and visibility information.
>> The only implementation is heapam.c
>> "secondary index" - i. They store some data and pointers to primary storage.
>> Various existing AMs and managed by AM API.
>> "virtual relations" - c, f, m. They have no physical storage, only entries
>> in caches and catalogs.
> Materialized views (relkind == "m") have physical storage, and may have indexes.
Good point. I сonfused letters for views (virtual relations) and
materialized views (primary storage).
Should be:
"primary storage" - r, S, t, m. They store data and visibility information.
The only implementation is heapam.c
"secondary index" - i. They store some data and pointers to primary storage.
Various existing AMs and managed by AM API.
"virtual relations" - c, f, v. They have no physical storage, only entries
in caches and catalogs.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-08-05 13:52:25 | Re: Heap WARM Tuples - Design Draft |
Previous Message | Amit Kapila | 2016-08-05 13:33:48 | Re: Cache Hash Index meta page. |