Re: Query Tunning related to function

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "Kumar, Mukesh" <MKumar(at)peabodyenergy(dot)com>
Cc: Bhupendra Babu <bbabu12(at)gmail(dot)com>, Michel SALAIS <msalais(at)msym(dot)fr>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>, MUKESH KUMAR <mukesh(dot)kumar14(at)tcs(dot)com>, "heda(dot)giriraj(at)tcs(dot)com" <heda(dot)giriraj(at)tcs(dot)com>
Subject: Re: Query Tunning related to function
Date: 2022-04-17 16:47:51
Message-ID: CAKFQuwYuRptm3SrSomOFgbA8gvgyHc_g8MEGmEjV_gJoMitccA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, Apr 17, 2022 at 8:53 AM Kumar, Mukesh <MKumar(at)peabodyenergy(dot)com>
wrote:

> We request you to please provide some assistance on below issue and it is
> impacting the migration project.
>

I suggest you try and re-write the loop-based function into a set-oriented
view.

Specifically, I think doing: "array_agg(DISTINCT paymenttype)" and then
checking for various array results will be considerably more efficient.

Or do a combination: write the set-oriented query in an SQL function. You
should not need pl/pgsql for this and avoiding it should improve
performance.

David J.

p.s., The convention on these lists is to inline post and remove unneeded
context. Or at least bottom post.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Benjamin Tingle 2022-04-17 17:07:50 Re: Query Planner not taking advantage of HASH PARTITION
Previous Message Tom Lane 2022-04-17 16:09:09 Re: Query Planner not taking advantage of HASH PARTITION