nning in
Heroku.
What are my options here? Currently, I'm planning to avoid these bad plans
by using a less straightforward query for the view:
SELECT
coalesce(contrib.id, cm.contribution_id) AS contribution_id,
coalesce(cm.yield, im.yield) AS yield,
coalesce(cm.term, im.term) AS term
FROM contribut
=17 loops=1)
Planning time: 0.396 ms
Execution time: 0.165 ms
schema here:
https://gist.github.com/awreece/aeacbc818277c7c6d99477645e7fcd03
Best,
~Alex
On Tue, Nov 28, 2017 at 2:13 AM Alex Reece wrote:
> I'm on PostgreSQL 9.6.5 and getting an awkwardly bad plan c
One more thing. Given this:
> The difference here is that, from the perspective of the outer query,
> the WHERE condition is a restriction clause on the "cim" relation,
> not a join clause. So it will get pushed down into the subquery
> without creating any join order constraints on the outer qu
I get very different plan chosen when my query is in a lateral subquery vs
standalone -- it doesn't use a key when joining on a table, instead opting
to do a hash join. Here is the query:
select distinct on (sub.entity_id, sub.note_id, sub.series_id)
entity_id, note_id, series_id
from
(
sel
contrib.investment_id)
Heap Fetches: 1792457
Planning time: 0.721 ms
Execution time: 7236.507 ms
On Tue, Dec 5, 2017 at 10:04 AM Alex Reece wrote:
> I get very different plan chosen when my query is in a lateral subquery vs
> standalone -- it doesn't us
ould prevent it from having to sort?
- What information can I gather to answer these questions on my own?
~Alex
On Tue, Dec 5, 2017 at 10:08 AM Alex Reece wrote:
> Weird, when I deleted an erroneous index it started picking a reasonable
> plan. This now works as expected, for posterity here
