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:
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
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
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
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
Shaheed Haque writes:
> ==
> foo =# explain analyse SELECT snapshot ->'company'->'legal_name' FROM
> paiyroll_payrun WHERE snapshot ->'employee' ? '2209';
> QUERY PLAN
>
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
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
