On 06/14/15 17:22, Alvaro Herrera wrote:
Robert Haas wrote:
,,,
Second, there's the idea of a way of storing tuples that is different
from PostgreSQL's usual mechanism - i.e. a storage manager API. I
understand your concerns about going through the FDW API so maybe
that's not the right way to do it, but it seems to me that in the end
you are going to end up with something awfully similar to that + a
local relfilenode + WAL logging support. I'm not clear on why you
want to make the column store API totally different from the FDW API;
there may be a reason, but I don't immediately see it.
I just don't see that the FDW API is such a good fit for what I'm trying
to do. Anything using the FDW API needs to implement its own visibility
checking, for instance. I want to avoid that, because it's its own
complex problem. Also, it doesn't look like the FDW API supports things
that I want to do (neither my proposed LateColumnMaterialization nor my
proposed BitmapColumnScan). I would have to extend the FDW API, then
contort my stuff so that it fits in the existing API; then I will need
to make sure that existing FDWs are not broken by the changes I would
propose elsewhere. Round peg, square hole is all I see here. All in
all, this seems too much additional work, just to make to things that
are really addressing different problems go through the same code.
You're correct about "local WAL logging". We will need a solution to
that problem. I was hoping to defer that until we had something like
Alexander Korotkov's proposed pluggable WAL stuff.
Probably worth mentioning we don't expect the column store API to be
used only by extensions, but even by code from within the core which can
use the current WAL infrastructure etc.
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
