From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AXLE Plans for 9.5 and 9.6 |
Date: | 2014-04-22 14:19:46 |
Message-ID: | 20140422141945.GL2556@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> I agree, and indeed that was something like my first reaction to
> hearing about this development - FDW seems like a very odd way to
> handle this. But the notion of builtin columnar storage suggests to
> me that we really need first to tackle how various storage engines
> might be incorporated into Postgres. I know this has been a bugbear
> for many years, but maybe now with serious proposals for alternative
> storage engines on the horizon we can no longer afford to put off
> the evil day when we grapple with it.
Agreed, and it goes beyond just columnar stores- I could see IOTs being
implemented using this notion of a different 'storage engine', but
calling it a 'storage engine' makes it sound like we want to change how
we access files and I don't think we really want to change that but
rather come up with a way to have an alternative heap.. Columnar or
IOTs would still be page-based and go through shared buffers, etc, I'd
think..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-04-22 15:06:22 | Re: Composite Datums containing toasted fields are a bad idea(?) |
Previous Message | Tom Lane | 2014-04-22 14:11:17 | Re: Store data in pg_toast for custom type fails (bug?) |