Re: Avoid detoast overhead when possible - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Avoid detoast overhead when possible
Date
Msg-id 87h68u8nqj.fsf@163.com
Whole thread Raw
In response to Re: Avoid detoast overhead when possible  (zhihuifan1213@163.com)
Responses Re: Avoid detoast overhead when possible
List pgsql-hackers
zhihuifan1213@163.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




pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: detoast datum into the given buffer as a optimization.
Next
From: Andrei Lepikhov
Date:
Subject: Re: Alias of VALUES RTE in explain plan