"Thomas Rosenstein" writes:
> On 9 Aug 2019, at 0:45, Tom Lane wrote:
>> I'm guessing about what that function does, but if you could
>> safely mark it stable or even immutable, I bet this view would
>> behave better.
> Yep that was IT! Perfect, thank you soo much!
> Why does it inhibit functiona
What a nice catch!
Sent from my iPad
On Aug 10, 2019, at 6:05 AM, Thomas Rosenstein
wrote:
>> [ re-adding list ]
>>
>> "Thomas Rosenstein" writes:
On 9 Aug 2019, at 0:45, Tom Lane wrote:
However ... it sort of looks like the planner didn't even consider
the second plan shape i
[ re-adding list ]
"Thomas Rosenstein" writes:
On 9 Aug 2019, at 0:45, Tom Lane wrote:
However ... it sort of looks like the planner didn't even consider
the second plan shape in the "wrong" case. If it had, then even
if it costed it 3X more than it did in the "right" case, the second
plan wo
[ re-adding list ]
"Thomas Rosenstein" writes:
> On 9 Aug 2019, at 0:45, Tom Lane wrote:
>> However ... it sort of looks like the planner didn't even consider
>> the second plan shape in the "wrong" case. If it had, then even
>> if it costed it 3X more than it did in the "right" case, the second
"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
