| 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?
--
Best Regards
Andy Fan
| 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. |