Re: Query is taking too long i intermittent

Поиск
Список
Период
Сортировка
От Mayank Kandari
Тема Re: Query is taking too long i intermittent
Дата
Msg-id CAArYVwhZsTEELz+PpPGMNTD69PZmZH=xKtZdtVBZH2Byqo-BYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query is taking too long i intermittent  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Thanks for the tip!  I will update my process and monitor it.

On Mon, Jun 6, 2022 at 7:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Mon, Jun 06, 2022 at 03:28:43PM +0530, Mayank Kandari wrote:
>> SELECT event_id FROM event WHERE (event_sec > time.seconds) OR
>> ((event_sec=time.seconds) AND (event_usec>=time.useconds) ORDER BY
>> event_sec, event_usec LIMIT 1

> I think it'd be better if the column was a float storing the fractional number
> of seconds.  Currently, it may be hard for the planner to estimate rowcounts if
> the conditions are not independent.  I don't know if it's related to this
> problem, though.

Also, even if you can't change the data representation, there's a more
idiomatic way to do that in SQL: use a row comparison.

SELECT ...
WHERE row(event_sec, event_usec) >= row(time.seconds, time.useconds) ...

I doubt this is notably more execution-efficient, but if you're getting a
bad rowcount estimate it should help with that.  It's easier to read too.

                        regards, tom lane


--
regards
Mayank Kandari

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Query is taking too long i intermittent
Следующее
От: Paulo Silva
Дата:
Сообщение: Strange behavior of limit clause in complex query