public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andy Fan <[email protected]>
To: Nikita Malakhov <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Avoid detoast overhead when possible
Date: Thu, 31 Oct 2024 09:11:14 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAN-LCVP8GHRMYDV4LLcAjBBjNS_rnx3q2hC8y=PY7xau9YsUzw@mail.gmail.com>
References: <[email protected]>
	<CAN-LCVMhwj6mGnjFg7hmNuTkwkyqHtiP8yVF_9DWuzXt2hT40Q@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAN-LCVP8GHRMYDV4LLcAjBBjNS_rnx3q2hC8y=PY7xau9YsUzw@mail.gmail.com>

Nikita Malakhov <[email protected]> writes:


> 1) In short the idea behind the Json improvements is to introduce iterators
> for Json objects to extract these objects value by value,

OK here.

> and modification
> of in-memory and on-disk representations to hold partially-detoasted Json
> objects (tree nodes with need-detoast state) for in-memory, and to store
> key-value map in on-disk representation to extract only required
> values.

I have troubles to follow here. Could you explain this more for the
below example, What will be done differently from current in the below
example: 

CREATE TABLE t(jbcol jsonb);

INSERT INTO t values ('{"a": 1, "b": 2}'); // new storage format?

SELECT jbcol->'a',  jbcol->'b' FROM t;   // How does ExprInterp.c work
with this? 


> 2) Backward compatibility would not be a problem because in on-disk
> representation we could distinguish old version from new.

OK, so you indeed change the storage format, if so, How is the new
format looks like? It would be an important factor to discuss. 

> there are enough service bits for that.

OK, good news.

> But servers not updated with this patch could not parse new data, of
> course.

This looks too for me. 

>
> 3) Yes, it definitely has to. These changes are very complex and invasive,
> that's the reason I haven't finished the patch.

This is the area I am really worried about. I think you can have some
high-level design document for review first. It would be great that some
more experienced people could have a look at, however I know it is hard
becuase of their bindwidth. You need that document anyway.

Without the details, other people is hard to understand the idea in
your mind. 

>
> 4) It doesn't seem worthy at first glance. Do you have any ideas on
> this?

I think the more important ones are (a) what the new storage looks like,
(b) how does it works with the ExprExecutionEnginner. Without that
infromation, I think it is too soon to talk about this.

-- 
Best Regards
Andy Fan

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Avoid detoast overhead when possible
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox