| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Cc: | 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>, Robert Haas <robertmhaas(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-09 14:32:19 |
| Message-ID: | 14421.1507559539@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> For me, it's crucial point that pluggable storages should be able to have
> different MVCC implementation, and correspondingly have full control over
> its interactions with indexes.
> Thus, it would be good if we would get consensus on that point. I'd like
> other discussion participants to comment whether they agree/disagree and
> why.
> Any comments?
TBH, I think that's a good way of ensuring that nothing will ever get
committed. You're trying to draw the storage layer boundary at a point
that will take in most of the system. If we did build it like that,
what we'd end up with would be very reminiscent of mysql's storage
engines, complete with inconsistent behaviors and varying feature sets
across engines. I don't much want to go there.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bossart, Nathan | 2017-10-09 14:52:27 | Re: Additional logging for VACUUM and ANALYZE |
| Previous Message | Alexander Korotkov | 2017-10-09 14:22:27 | Re: Pluggable storage |