Re: Autonomous transactions 2023, WIP
От | Ivan Kush |
---|---|
Тема | Re: Autonomous transactions 2023, WIP |
Дата | |
Msg-id | 5687999a-7382-4b23-9e15-be8222e1c4af@tantorlabs.com обсуждение исходный текст |
Ответ на | Re: Autonomous transactions 2023, WIP (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Autonomous transactions 2023, WIP
|
Список | pgsql-hackers |
On 01.01.2024 09:47, Pavel Stehule wrote: > > > All use cases of pg_background, except asynchronous execution. If > later > add asynchronous execution, then all =) > > For example, also: > > * conversion from Oracle's `PRAGMA AUTONOMOUS` to Postgres. > > * possibility to create functions that calls utility statements, like > VACUUM, etc. > > > almost all these tasks are more or less dirty. It is a serious > question if we want to integrate pg_background to core. What do you mean by the "dirty"? > > I don't have good benchmarks now. Some simple, like many INSERTs. > Pool > gives advantage, more tps compared to pg_background with increasing > number of backends. > > The main advantage over pg_background is pool of workers. In this > patch > separate pool is created for each backend. At the current time I'm > coding one shared pool for all backends. > > > I afraid so this solution can be very significantly slower than > logging to postgres log or forwarding to syslog Maybe. Need to benchmark. Also OLAP like ClickHouse is better for storing logs. But in this case (log file -> database) a company needs to write a custom utility to load log file to the database: * detect file size, * load to database * autorotate file by timeout of filesize * etc. Some of our customers use "Autonomous transactions" for logging =) -- Best wishes, Ivan Kush Tantor Labs LLC
В списке pgsql-hackers по дате отправления: