| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(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-10-13 18:41:14 |
| Message-ID: | CA+TgmoYR_dn7NqN5eb904uzf9H98hpLQiibXAckwnOPEKDiSLw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 13, 2017 at 1:59 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>> Fully agreed.
>
> If we implement that interface, where does that leave EvalPlanQual()?
> Do those semantics have to be preserved?
For a general-purpose heap storage format, I would say yes.
I mean, we don't really have control over how people use the API. If
somebody decides to implement a storage API that breaks EvalPlanQual
semantics horribly, I can't stop them, and I don't want to stop them.
Open source FTW.
But I don't really want that code in our tree, either. I think a
storage engine is and should be about the format in which data gets
stored on disk, and that it should only affect the performance of
queries not the answers that they give. I am sure there will be cases
where, for reasons of implementation complexity, that turns out not to
be true, but I think in general we should try to avoid it as much as
we can.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | legrand legrand | 2017-10-13 18:47:51 | Re: Continuous integration on Windows? |
| Previous Message | Robert Haas | 2017-10-13 18:37:10 | Re: Pluggable storage |