From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Shaheed Haque <shaheedhaque(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: JSONB index not in use, but is TOAST the real cause of slow query? |
Date: | 2022-05-28 19:58:09 |
Message-ID: | 32fd4aed-f879-9d45-208c-b53e9eb6903c@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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. I'll have a play with
> the knobs you suggested and will report back with anything of note.
>
> 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?
See:
https://www.postgresql.org/docs/current/storage-toast.html
and from there:
https://www.postgresql.org/docs/current/sql-altertable.html
Search for SET STORAGE.
It might help with(from Tom Lane):
"Unfortunately the planner doesn't account
for detoasting costs when making such estimates, ..."
but probably not much with:
" ...because anything at all that you do with
that big JSONB column is going to be expensive. (Another thing
that's been on the to-do list for awhile is enabling partial
retrieval of large JSONB values, but AFAIK that hasn't happened
yet either.)
>
> Thanks, Shaheed
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-05-28 19:59:12 | Re: JSONB index not in use, but is TOAST the real cause of slow query? |
Previous Message | Shaheed Haque | 2022-05-28 19:38:34 | Re: JSONB index not in use, but is TOAST the real cause of slow query? |