Dear developers:
I have some suggestions on PostgreSQL's IO behavior. I am not sure my opinions
are right. Many thanks for your time!
It is documented that :
wal_sync_method (enum): The open_* options also use O_DIRECT if available.
Shall PostgreSQL consider making O_DIRECT configurable? In My
Hi,
I have a database table with a modest number of rows (<1000) but where
one column in the table is a JSONB "snapshot" which can be a few MB in
size. Generally, this is a great fit for the read-write access
patterns involved, but there is a read-query which is VERY slow.
I've searched via Googl
Shaheed Haque writes:
> ==
> foo =# explain analyse SELECT snapshot ->'company'->'legal_name' FROM
> paiyroll_payrun WHERE snapshot ->'employee' ? '2209';
> QUERY PLAN
> --
Tom,
Thanks for the considered advice and insights. My takeaway is that
based on what I've said,you are mostly unsurprised by the results I
see. In the longer term, the number of rows will increase but I will
have to ponder options for the immediate future. I'll have a play with
the knobs you sugg
On 5/28/22 12:38, Shaheed Haque wrote:
Tom,
Thanks for the considered advice and insights. My takeaway is that
based on what I've said,you are mostly unsurprised by the results I
see. In the longer term, the number of rows will increase but I will
have to ponder options for the immediate future.
Shaheed Haque writes:
> One last thought about TOAST. If the cost of the -> retrieving the
> data cannot be obviated, is there any way to tweak how that works?
The only thing that's readily tweakable is to disable data compression
for the out-of-line values (see ALTER TABLE ... SET STORAGE, and n
On Sun, May 29, 2022 at 4:29 AM 浩辰 何 wrote:
> Furthermore, the results above are also related to IO API supported by OS.
> MySQL support synchronized IO and Linux libaio. It seems
> that PostgreSQL only supports synchronized IO, so shall we support more IO
> engines? like io_uring which is very
Adrian, Tom, thanks for the input. Based on that, it occurred to me to
create some "dummy" rows and - almost magically - the index kicks in!
Before is 2500ms:
Seq Scan on paiyroll_payrun (cost=0.00..52.43 rows=17 width=32)
(actual time=53.127..2567.024 rows=104 loops=1)
Filter: ((s
