On 7 May 2014 18:39, Stephen Frost <sfr...@snowman.net> wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: >> On 7 May 2014 17:43, Stephen Frost <sfr...@snowman.net> wrote: >> > It's the optimizer's job to figure out which path to pick though, based >> > on which will have the lowest cost. >> >> Of course. I'm not suggesting otherwise. >> >> >> If do you want that, you can write an Event Trigger that automatically >> >> adds a lookaside for any table. >> > >> > This sounds terribly ugly and like we're pushing optimization decisions >> > on to the user instead of just figuring out what the best answer is. >> >> I'm proposing that we use a declarative approach, just like we do when >> we say CREATE INDEX. > > There's quite a few trade-offs when it comes to indexes though. I'm > trying to figure out when you wouldn't want to use a GPU, if it's > available to you and the cost model says it's faster? To me, that's > kind of like saying you want a declarative approach for when to use a > HashJoin.
I'm proposing something that is like an index, not like a plan node. The reason that proposal is being made is that we need to consider data structure, data location and processing details. * In the case of Mat Views, if there is no Mat View, then we can't use it - we can't replace that with just any mat view instead * GPUs and other special processing units have finite data transfer rates, so other people have proposed that they retain data on the GPU/SPU - so we want to do a lookaside only for situations where the data is already prepared to handle a lookaside. * The other cases I cited of in-memory data structures are all pre-arranged items with structures suited to processing particular types of query Given that I count 4-5 beneficial use cases for this index-like lookaside, it seems worth investing time in. It appears that Kaigai wishes something else in addition to this concept, so there may be some confusion from that. I'm sure it will take a while to really understand all the ideas and possibilities. -- 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
