From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A thought on Index Organized Tables |
Date: | 2010-02-22 10:29:54 |
Message-ID: | 407d949e1002220229w1e781755jd1754dbf94201ba7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 22, 2010 at 8:18 AM, Gokulakannan Somasundaram
<gokul007(at)gmail(dot)com> wrote:
> a) IOT has both table and index in one structure. So no duplication of data
> b) With visibility maps, we have three structures a) Table b) Index c)
> Visibility map. So the disk footprint of the same data will be higher in
> postgres ( 2x + size of the visibility map).
These sound like the same point to me. I don't think we're concerned
with footprint -- only with how much of that footprint actually needs
to be scanned. So if we have a solution allowing the scan to only need
to look at the index then the extra footprint of the table doesn't
cost anything at run-time. And the visibility map is very small.
I think you would be better off looking for incremental improvements
rather than major architectural changes like having no heap for a
table. There are so many design decisions hinged on having a heap that
it would be impractical to rethink them all.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Gokulakannan Somasundaram | 2010-02-22 11:01:49 | Re: A thought on Index Organized Tables |
Previous Message | Greg Stark | 2010-02-22 10:15:18 | Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |