Re: [GENERAL] Poor performance on 9.4.4 when matching multiple columns from left side of LATERAL join

Steven Grimm writes: > It is puzzling that if, as suggested by someone else in the thread, I > expand IN(a,b,c) to (x = a OR x = b OR x = c) it gets substantially > faster, though still obviously falls afoul of the problem you describe > above (~4 seconds instead of ~6 seconds). Should those tw

Re: [GENERAL] Poor performance on 9.4.4 when matching multiple columns from left side of LATERAL join

David Rowley November 14, 2015 at 12:32 AM The problem is that the optimizer is unable to use hash join or merge joins when you have the IN() condition as the join condition, the reason for this is that you're effectively saying to join on any of 3 condit

Re: [GENERAL] fast refresh materialized view

On Friday, November 13, 2015 4:02 PM, "Pradhan, Sabin" wrote: > Does postgres has fast refresh materialized view that supports > incremental refresh. In oracle , this is achieve by materialized > view log. Not sure how to implement it in postgres. There has been work toward that end, but f

[GENERAL] Re: Poor performance on 9.4.4 when matching multiple columns from left side of LATERAL join

Steven Grimm schrieb am 14.11.2015 um 07:25: We have a table, call it "multi_id", that contains columns with IDs of various kinds of objects in my system, and another table that's a generic owner/key/value store for object attributes (think configuration settings, and I'll refer to this table a

Re: [GENERAL] Poor performance on 9.4.4 when matching multiple columns from left side of LATERAL join

On 14 November 2015 at 19:25, Steven Grimm wrote: > > Execution plan for the IN version followed by the = version (for just one > of the IDs): > > - > Nested Loop (cost=5.39..8107.18 rows=285 width=4) (actual > time=1.230..6456.567 rows=4499 loops=1) >