On 8 May 2014 03:36, Stephen Frost <sfr...@snowman.net> wrote: >> Given that I count 4-5 beneficial use cases for this index-like >> lookaside, it seems worth investing time in. > > I'm all for making use of MatViews and GPUs, but there's more than one > way to get there and look-asides feels like pushing the decision, > unnecessarily, on to the user.
I'm not sure I understand where most of your comments come from, so its clear we're not talking about the same things yet. We have multiple use cases where an alternate data structure could be used to speed up queries. My goal is to use the alternate data structure(s) 1) if the data structure contains matching data for the current query 2) only when the user has explicitly stated it would be correct to do so, and they wish it 3) transparently to the application, rather than forcing them to recode 4) after fully considering cost-based optimization, which we can only do if it is transparent all of which is how mat views work in other DBMS. My additional requirement is 5) allow this to work with data structures outside the normal heap/index/block structures, since we have multiple already working examples of such things and many users wish to leverage those in their applications which I now understand is different from the main thrust of Kaigai's proposal, so I will restate this later on another thread. The requirement is similar to the idea of running CREATE MATERIALIZED VIEW foo BUILD DEFERRED REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE ON PREBUILT TABLE but expands on that to encompass any external data structure. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
