Re: proposal - log_full_scan
От | Pavel Stehule |
---|---|
Тема | Re: proposal - log_full_scan |
Дата | |
Msg-id | CAFj8pRC-MdjE+deaZdsyM3KT=+W=3L8jP-tDQYzji0MLLqAMBw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal - log_full_scan (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-hackers |
so 17. 4. 2021 v 18:54 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
On Sat, Apr 17, 2021 at 05:22:59PM +0200, Pavel Stehule wrote:
>
> The fullscan of this table needs about 30ms and has 200K rows. So
> decreasing log_min_duration to this value is very risky.
>
> [...]
>
> I use pg_stat_all_tables.seq_scan and I see seq scans there. But I need to
> know the related queries.
Maybe you could use pg_qualstats ([1]) for that? It will give you the list of
quals (with the underlying queryid) with a tag to specify if they were executed
as an index scan or a sequential scan. It wouldn't detect queries doing
sequential scan that don't have any qual for the underlying relations, but
those shouldn't be a concern in your use case.
If you setup some sampling, the overhead should be minimal.
[1]: https://github.com/powa-team/pg_qualstats/
It has similar functionality - there is a problem with setting. The my idea is more simple - just
set
log_fullscall_min_tupples = 100000
or
alter table xxx set log_fullscan_min_tupples = 0;
and then the complete query can be found in the log.
I think this can be really practical so it can be core functionality. And it can log the queries without
quals too. The productions systems can be buggy and it is important to find bugs
Regards
Pavel
В списке pgsql-hackers по дате отправления: