Re: pgBadger and postgres_fdw

On 1/21/26 08:59, Adrian Klaver wrote:
> On 1/21/26 08:12, Colin 't Hart wrote:
> 
>> 6. The 19 slowest queries in a 4 hour period are between 2 and 37 
>> minutes, with an average of over 10 minutes; they are all `fetch 100 
>> from c2`.
>>
>> The slowness itself isn't my question here; it was caused by having 
>> too few cores in the new environment, while the application was still 
>> assuming the higher core count and generating too many concurrent 
>> processes.
>>
>> My question is how to identify which connections / queries from 
>> postgres_fdw are generating the `fetch 100 from c2` queries, which, in 
>> turn, may quite possibly lead to a feature request for having these 
>> named uniquely.
> 
> My guess not.
> 
> See:
> 
> https://github.com/postgres/postgres/blob/master/contrib/postgres_fdw/ 
> postgres_fdw.c
> 
> Starting at line ~5212
> 
> fetch_size = 100;
> 
> and ending at line ~5234
> 
> /* Construct command to fetch rows from remote. */
>      snprintf(fetch_sql, sizeof(fetch_sql), "FETCH %d FROM c%u",
>               fetch_size, cursor_number);
> 
> So c2 is a cursor number.

If I am following this something postgres_fdw does to fetch the result 
in batches, so all the queries will have them.

FYI, the  fetch_size can be changed, see here:

https://www.postgresql.org/docs/17/postgres-fdw.html#POSTGRES-FDW-CONFIGURATION-PARAMETERS

F.36.1.4. Remote Execution Options


If you want connection/query information I would enable from here:

https://www.postgresql.org/docs/17/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT

log_connections

log_disconnections

And at least temporarily:

log_statement = 'all'

The above will generate a lot of logs so you don't want to keep set for 
too long.


> 
>>
>> Thanks,
>>
>> Colin
>>
> 
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com