From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Ashwin Agrawal <aagrawal@pivotal.io>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: Zedstore - compressed in-core columnar storage
Date: Mon, 15 Apr 2019 15:36:44 -0400
Message-ID: <23412.1555357004@sss.pgh.pa.us> (raw)
In-Reply-To: <20190415192004.od3paxoo5rlogmm4@alap3.anarazel.de>
References: <bf4b8f5f-90c9-025d-013c-87cf998204ad@postgrespro.ru>
<20190409155121.GA4320@alvherre.pgsql>
<CA+TgmoardtfM+0nfj=g1qrH5khuHP6Oi5ZS546CLx_iQUG620g@mail.gmail.com>
<20190414162210.6djspkmbspbd4els@development>
<20190415123424.GD6197@tamriel.snowman.net>
<30261.1555341038@sss.pgh.pa.us>
<CA+TgmoYgatemjoKjOGg3wZ91_OkiEwqQ_cM4fGvYmvr9Kc=a3w@mail.gmail.com>
<20789.1555353343@sss.pgh.pa.us>
<20190415192004.od3paxoo5rlogmm4@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> We also have at times pretty explicitly resisted making crucial pieces
> of infrastructure usable outside of core. E.g. because it's legitimately
> hard (grammar extensibility), or because we'd some concerns around
> stability and the exact approach (WAL - the generic stuff is usable for
> anything that wants to even be somewhat efficient, some xlog
> integration). So there's several types of extensions that one
> realistically cannot do out of core, by our choice.
Well, the grammar issue comes from a pretty specific technical problem:
bison grammars don't cope with run-time extension, and moving off of bison
would cost a lot of work, and probably more than just work (i.e., probable
loss of ability to detect grammar ambiguity). WAL extensibility likewise
has some technical issues that are hard to surmount (how do you find the
code for replaying an extension WAL record, when you can't read catalogs).
I think we could fix the latter, it's just that no one has yet troubled
to expend the effort. Similarly, things like the planner's hard-wired
handling of physical-tlist optimization are certainly a problem for
column stores, but I think the way to solve that is to provide an actual
extension capability, not merely replace one hard-wired behavior with two.
As a counterpoint to my gripe about SP-GiST being a time sink, I do not
think I'll regret the time I spent a few months ago on implementing
"planner support function" hooks. I'm all in favor of adding flexibility
like that.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, robertmhaas@gmail.com, sfrost@snowman.net, tomas.vondra@2ndquadrant.com, alvherre@2ndquadrant.com, k.knizhnik@postgrespro.ru, aagrawal@pivotal.io
Subject: Re: Zedstore - compressed in-core columnar storage
In-Reply-To: <23412.1555357004@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox