Hans Buschmann writes:
> The planner correctly sets the index conditions (knows that the xx_season
> columns are constant), but fails to apply this constantness to the hash
> conditions by discarding a constant column in a hash table.
Yeah. The reason for this behavior is that, after
Thanks for looking at it.
I think these two queries are equivalent, as shown by the explain.
In both cases the index scan only selects tuples with xx_season=3 as shown in
both explains:
Index Cond: (tmaster.t1_season = 3)
Index Cond: (tfact.t2_season = 3)
So no tuple
On Fri, Oct 18, 2019 at 03:40:34PM +, Hans Buschmann wrote:
...
Both queries are logically equivalent. The planner correctly identifies
the Index Cond: (tfact.t2_season = 3) for selecting from the index
uk_fact_season_id.
Are those queries actually equivalent? I've been repeatedly
Hi Hackers,
By optimising our application I stumbled over the join quals used very often in
our application.
In general this concerns datasets, which are subdivided into chunks, like
years, seasons (here half a year), multiple tenants in OLTP system etc.
In these cases many tables are joined
