Hi all,
long time ago I devised with your help a task queuing system which uses
SELECT ... FOR UPDATE SKIP LOCKED for many parallel workers to find
tasks in the queue, and it used a partitioned table where the hot part
of the queue is short and so the query for a job is quick and the skip
loc
On Tue, Jun 30, 2020 at 1:02 AM Nikhil Shetty
wrote:
> Hi Bruce,
>
> Based on pg_test_fsync results, should we choose open_datasync or
> fdatasync as wal_sync_method? Can we rely on pg_test_fsync for choosing the
> best wal_sync_method or is there any other way?
>
Probably the default of fdatasy
On Mon, Jun 29, 2020 at 5:27 AM Nikhil Shetty
wrote:
> Hi Team,
>
> We have a PostgreSQL 11.5.6 database running on VM.
> RAM - 48GB
> CPU - 6 cores
> Disk - SSD on SAN
>
> We wanted to check how the WAL disk is performing using pg_test_fsync.We
> ran a test and got around 870 ops/sec for opendat
On Tue, Jun 30, 2020 at 10:32:13AM +0530, Nikhil Shetty wrote:
> Hi Bruce,
>
> Based on pg_test_fsync results, should we choose open_datasync or fdatasync as
> wal_sync_method? Can we rely on pg_test_fsync for choosing the best
I would just pick the fastest method, but if the method is _too_ fast
