On Thu, 6 Feb 2020 at 11:12, Adam Brusselback wrote:
>
> > You can create a library of
> > reusable views that are small, easy-to-understand and readable. Then
> > you build them up into bigger views, and finally query from them. But
> > then you end up with lots of (hidden) self-joins.
>
> I will
> You can create a library of
> reusable views that are small, easy-to-understand and readable. Then
> you build them up into bigger views, and finally query from them. But
> then you end up with lots of (hidden) self-joins.
I will concur with this use case being pretty common, but also something
Thank you for your response. I have tested out the patch in the linked
thread and it works very well on a bunch of complex queries that I
have tested, improving both the planning time significantly and the
execution time drastically.
I have also read through the entire linked discussion thread as
Benny Kramek writes:
> I expect the query plan to be identical for both of the below queries (and I
> expect the performance to also be identical).
[ shrug... ] Your expectation is mistaken. There is no code in Postgres
to eliminate useless self-joins. People have been fooling around with
a pat
Hello,
I am experiencing slow performance when joining a table against itself on its
primary key column.
I expect the query plan to be identical for both of the below queries (and I
expect the performance to also be identical). But the second one is much slower:
The FAST QUERY has a planning tim
