"Thomas Rosenstein" writes:
> The planner estimates the correct row counts, but still does the wrong
> planning.
Hm, I'm not exactly convinced. You show
> Wrong:
> -> Hash Join (cost=359555.11..1849150.95 rows=1496816
> width=1508) (actual time=1081.081..24251.466 rows=543231 loop
To add additional info, the same behaviour is exhibited with the owner,
and the user which only has read priviledges on the view!
On 8 Aug 2019, at 22:04, Thomas Rosenstein wrote:
Hi,
I'm upgraded to 10.10 from today (on the replicated instance - main db
is still 10.5), but still have the is
Hi,
I'm upgraded to 10.10 from today (on the replicated instance - main db
is still 10.5), but still have the issue.
The table is owned by the user "creamfinance", and the view is also
owned by the same user - based on the text you quoted this should allow
the correct access.
The planner e
"Thomas Rosenstein" writes:
> we have created restricted view for our tables, so that we can allow
> access to non-gdpr relevant data but hide everything else.
> For exactly those views, the Query Planner uses the wrong indices, when
> executing exactly the same query, once it takes 0.1 s and on
Hi,
we have created restricted view for our tables, so that we can allow
access to non-gdpr relevant data but hide everything else.
For exactly those views, the Query Planner uses the wrong indices, when
executing exactly the same query, once it takes 0.1 s and on the views
it takes nearly 1
