MIME-Version: 1.0
In-Reply-To: <1509701327868-0.post@n3.nabble.com>
References: <f1b85c37-e4b5-c158-5f67-a780a2191e20@gusw.net>
 <1509611428.3268.5.camel@cybertec.at> <1509701327868-0.post@n3.nabble.com>
From: Adam Brusselback <adambrusselback@gmail.com>
Date: Fri, 3 Nov 2017 08:07:13 -0400
Message-ID: 
 <CAMjNa7dy23vwG4UEoTe+xcgJF6xj7bptVra_-BgieGTpJUYOSg@mail.gmail.com>
Subject: Re: Re: OLAP/reporting queries fall into nested loops over
 seq scans or other horrible planner choices
To: Thomas Kellerer <spam_eater@gmx.net>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Fri, Nov 3, 2017 at 5:28 AM, Thomas Kellerer <spam_eater@gmx.net> wrote:
> I do like Oracle's approach with SQL profiles, where you can force the
> optimizer to try harder to find a good execution plan. I _think_ it even
> runs the statement with multiple plans and compares the expected outcome
> with the actual values. Once a better plan is found that plan can be
> attached to that query and the planner will use that plan with subsequent
> executions.

I also think that this is a really cool approach.  For those specific
problem queries, pretty much tell the optimizer "do your best to make
this as efficient as possible".

To make that more useful though, you'd probably need a shared query
cache that would be persisted through restarts.  I'd assume if you
have a problem query, this very heavy "planning / optimization"
operation would not be something you wanted every connection to have
to do every time they connect.

I wish I was more knowledgeable about the internals so I could more
clearly see how a system like that could come together, and what other
groundwork would be needed building up to it.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance