Re: Avoid detoast overhead when possible

From: Andy Fan <zhihuifan1213(at)163(dot)com>
To: Nikita Malakhov <hukutoc(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Avoid detoast overhead when possible
Date: 2024-10-29 23:59:16
Message-ID: 87h68u8nqj.fsf@163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

zhihuifan1213(at)163(dot)com writes:

Hello Nikita,

>> There's a view from the other angle - detoast just attributes that are needed
>> (partial detoast), with optimized storage mechanics for JSONb.
>
> Very glad to know that, looking forward your design & patch!

This is interesting, do you mind to provide a high level design of
this. I'm not pushing to do this, but you asked me how I think about
your proposal[1], so I think a high level design is a must to for these
question. A first set of questions includes:

1. How to optimize the JSONb storage?
2. How to be compatible with older version?
3. How to integreate with existing ExprExecutionEngine? looks your
proposal needs to know which "part" of jsonb fields are needed.
4. Is there any optimization if user want to get a full JSONB, like
SELECT jb_col FROM t?

[1]
https://www.postgresql.org/message-id/CAN-LCVO3GZAKVTKNwwcezoc%3D9Lq%3DkU2via-BM3MXVdOq4tD9RQ%40mail.gmail.com

--
Best Regards
Andy Fan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2024-10-30 01:54:48 Re: Alias of VALUES RTE in explain plan
Previous Message Andy Fan 2024-10-29 23:47:06 Re: detoast datum into the given buffer as a optimization.