Re: Autonomous transactions 2023, WIP

From: Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autonomous transactions 2023, WIP
Date: 2024-01-01 11:15:27
Message-ID: 5687999a-7382-4b23-9e15-be8222e1c4af@tantorlabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2024-01-01 11:47:19 Re: Track in pg_replication_slots the reason why slots conflict?
Previous Message Amit Kapila 2024-01-01 11:00:41 Re: Track in pg_replication_slots the reason why slots conflict?