Re: A way to optimize sql about the last temporary-related row

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "agharta82(at)gmail(dot)com" <agharta82(at)gmail(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: A way to optimize sql about the last temporary-related row
Date: 2024-06-27 15:33:18
Message-ID: CAKFQuwb=EDKdxozCvkb1HqEcnBAzcCyNnOp=2Ywxyf2HdXV8ZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thursday, June 27, 2024, agharta82(at)gmail(dot)com <agharta82(at)gmail(dot)com> wrote:

>
> Now the query:
> explain (verbose, buffers, analyze)
> with last_table_ids as materialized(
> select xx from (
> select LAST_VALUE(pk_id) over (partition by integer_field_2 order by
> datetime_field_1 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
> xx
> from test_table
> where integer_field_1 = 1
> and datetime_field_1 <= CURRENT_TIMESTAMP
> ) ww group by ww.xx
>
> ),
> last_row_per_ids as (
> select tt.* from last_table_ids lt
> inner join test_table tt on (tt.pk_id = lt.xx)
>
> )
>
> select * /* or count(*) */ from last_row_per_ids;
>
>
> Do you think there is a way to optimize the query?

Write a lateral subquery to pick the first row of a descending ordered
query? Using group to select ranked rows is both semantically wrong and
potentially optimization blocking.

I’m going by the general query form and the “last row” aspect of the
question. I haven’t gone and confirmed your specific query can benefit
from this approach. The window expression does give me pause.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2024-06-27 15:43:47 Re: A way to optimize sql about the last temporary-related row
Previous Message agharta82@gmail.com 2024-06-27 15:33:13 Re: A way to optimize sql about the last temporary-related row