On Fri, Nov 12, 2021 at 09:12:38PM +0100, Jiří Fejfar wrote:
> * I know that PG is focused on OLTP rather then analytics, but we are happy
> with it at all and do not wish to use another engine for analytical
> queries... isn't somewhere some "PG analytical best practice" available?
It's a good qu
On Fri, 12 Nov 2021 at 03:41, Justin Pryzby wrote:
> On Thu, Nov 11, 2021 at 08:20:57PM +0100, Jiří Fejfar wrote:
> > Hi folks,
> >
> > we have found that (probably after VACUUM ANALYZE) one analytical query
> > starts to be slow on our production DB. Moreover, more or less the same
> > plan is u
On Fri, Nov 12, 2021 at 10:55:53AM -0700, Michael Lewis wrote:
> On Thu, Nov 11, 2021 at 7:42 PM Justin Pryzby wrote:
>
> > BTW, we disable nested loops for the our analytic report queries. I have
> > never
> > been able to avoid pathological plans any other way.
>
> Curious, do you see any pro
On Thu, Nov 11, 2021 at 7:42 PM Justin Pryzby wrote:
> BTW, we disable nested loops for the our analytic report queries. I have
> never
> been able to avoid pathological plans any other way.
>
Curious, do you see any problems from that? Are there certain nodes that
really are best suited to a n
On Thu, Nov 11, 2021 at 08:20:57PM +0100, Jiří Fejfar wrote:
> Hi folks,
>
> we have found that (probably after VACUUM ANALYZE) one analytical query
> starts to be slow on our production DB. Moreover, more or less the same
> plan is used on our testing data (how to restore our testing data is
> de
