Re: Query optimization

On Thu, Mar 13, 2025 at 11:49 PM Durgamahesh Manne < maheshpostgr...@gmail.com> wrote: > To return one row takes 43ms is not optimal > It's actually much faster than that, but even 43ms is overall good. The query is already pretty optimal, as it uses a single index only scan. There are a few tric

Re: Query optimization

On Fri, 14 Mar, 2025, 09:11 Ron Johnson, wrote: > On Thu, Mar 13, 2025 at 11:25 PM Durgamahesh Manne < > maheshpostgr...@gmail.com> wrote: > >> On Fri, Mar 14, 2025 at 8:19 AM Ron Johnson >> wrote: >> >>> On Thu, Mar 13, 2025 at 10:16 PM Durgamahesh Manne < >>> maheshpostgr...@gmail.com> wrote:

Re: Query optimization

> > 3) Output of EXPLAIN ANALYZE of query. > > Result (cost=2.80..2.83 rows=1 width=1) (actual time=0.030..0.030 rows=1 > loops=1) >InitPlan 1 (returns $0) > -> Index Only Scan using idx_cachekeys on cachekeys (cost=0.55..2.80 > rows=1 width=0) (actual time=0.029..0.029 rows=1 lo

Re: Query optimization

> On Mar 13, 2025, at 8:39 PM, Durgamahesh Manne > wrote: > > > > On Fri, 14 Mar, 2025, 08:04 Rob Sargent, > wrote: > > Hi > > Gave you plan with out limit . Stats up to date insert .on conflict do > nothing runs some times > > Regards > Durga Mahesh

Re: Query optimization

On Thu, Mar 13, 2025 at 11:48 PM Durgamahesh Manne < maheshpostgr...@gmail.com> wrote: > On Fri, 14 Mar, 2025, 09:11 Ron Johnson, wrote: > >> On Thu, Mar 13, 2025 at 11:25 PM Durgamahesh Manne < >> maheshpostgr...@gmail.com> wrote: >> >>> On Fri, Mar 14, 2025 at 8:19 AM Ron Johnson >>> wrote: >>

Re: Query optimization

On Thursday, March 13, 2025, Durgamahesh Manne wrote: > > > > > >

Re: Query optimization

On Thu, Mar 13, 2025 at 11:25 PM Durgamahesh Manne < maheshpostgr...@gmail.com> wrote: > On Fri, Mar 14, 2025 at 8:19 AM Ron Johnson > wrote: > >> On Thu, Mar 13, 2025 at 10:16 PM Durgamahesh Manne < >> maheshpostgr...@gmail.com> wrote: >> [snip] >> >>> Hi Adrian Klaver >>> >>> 1) Postgres versio

Re: Query optimization

On Fri, Mar 14, 2025 at 8:19 AM Ron Johnson wrote: > On Thu, Mar 13, 2025 at 10:16 PM Durgamahesh Manne < > maheshpostgr...@gmail.com> wrote: > [snip] > >> Hi Adrian Klaver >> >> 1) Postgres version. >> select version(); >> version >> >> --

Re: Query optimization

On Thu, Mar 13, 2025 at 10:16 PM Durgamahesh Manne < maheshpostgr...@gmail.com> wrote: [snip] > Hi Adrian Klaver > > 1) Postgres version. > select version(); > version > > -

Re: Query optimization

On Fri, 14 Mar, 2025, 08:04 Rob Sargent, wrote: > > > > 3) Output of EXPLAIN ANALYZE of query. > > Result (cost=2.80..2.83 rows=1 width=1) (actual time=0.030..0.030 rows=1 > loops=1) >InitPlan 1 (returns $0) > -> Index Only Scan using idx_cachekeys on cachekeys > (cost=0.55..2.80 row

Re: Query optimization

On Fri, Mar 14, 2025 at 12:47 AM Adrian Klaver wrote: > On 3/13/25 12:12, Durgamahesh Manne wrote: > > Hi Team > > > > This query takes more time than usual for execution > > Define usual. > > > > How to optimize it in best possible way > > Can't be answered without, to start: > > 1) Postgres ver

Re: Query optimization

On Fri, 2025-03-14 at 00:42 +0530, Durgamahesh Manne wrote: > This query takes more time than usual for execution  > > How to optimize it in best possible way > > Columns used in this query >> composite index eventhough not running > optimally  > SELECT EXISTS (SELECT Key FROM CACHEKEYS WHERE Ca

Re: Query optimization

On 3/13/25 12:12, Durgamahesh Manne wrote: Hi Team This query takes more time than usual for execution Define usual. How to optimize it in best possible way Can't be answered without, to start: 1) Postgres version. 2) Complete(including indexes) table schema. 3) Output of EXPLAIN ANALY

Re: Query optimization with repeated calculations

Robert McGehee writes: > I frequently want to make views that repeat a calculation over and over > again in lots of columns. In the example below, let’s say it’s (a+b), but > we can imagine the calculation being much more complicated. > For example: > CREATE VIEW AS > SELECT (a+b)*c as c1, (a+b)*