| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, knizhnik <knizhnik(at)garret(dot)ru> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com> |
| Subject: | Re: In-Memory Columnar Store |
| Date: | 2013-12-11 18:52:22 |
| Message-ID: | 1386787942.33209.YahooMailNeo@web162901.mail.bf1.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> wrote:
> The question I have, which applies to the matview support as
> well, is "How can we transparently substitute usage of the
> in-memory columnar store/matview in a SQL query?".
My take on that regarding matviews is:
(1) It makes no sense to start work on this without a far more
sophisticated concept of matview "freshness" (or "staleness", as
some products prefer to call it).
(2) Work on query rewrite to use sufficiently fresh matviews to
optimize the execution of a query and work on "freshness" tracking
are orthogonal to work on incremental maintenance.
I have no plans to work on either matview freshness or rewrite, as
there seems to be several years worth of work to get incremental
maintenance up to a level matching other products. I welcome
anyone else to take on those other projects.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-12-11 19:03:37 | Re: Extension Templates S03E11 |
| Previous Message | Tom Lane | 2013-12-11 18:51:51 | Re: stats for network traffic WIP |