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
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
described at the end of this email), or better to say the same problem
exis
