Nikita Malakhov 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 n
Hi!
Sorry for the long delay, other tasks required my attention and this project
was postponed, but we have some recent requests from clients and this
work has to be revived.
1) In short the idea behind the Json improvements is to introduce iterators
for Json objects to extract these objects valu
zhihuifan1...@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 pro
Hi
Nikita Malakhov writes:
>
> With your setup (table created with setup.sql):
You need to "set jit to off" to turn on this feature, as I state in [1]
[2].
[1] https://www.postgresql.org/message-id/87ttoyihgm.fsf%40163.com
[2] https://www.postgresql.org/message-id/877cltvxgt.fsf%40163.com
-
Hi,
With your setup (table created with setup.sql):
postgres@postgres=# explain analyze select big->'1', big->'2', big->'3',
big->'5', big->'10' from b;
QUERY PLAN
Nikita Malakhov writes:
> Hi,
>
> Hmmm, I've checked this patch and can't see performance difference on a large
> (2 key-value pairs) json, using toasted json column several times makes no
> difference between current implementation on master (like queries mentioned
> above).
>
> Maybe I'm
Hi,
Hmmm, I've checked this patch and can't see performance difference on a
large
(2 key-value pairs) json, using toasted json column several times makes
no
difference between current implementation on master (like queries mentioned
above).
Maybe I'm doing something wrong?
On Tue, Dec 5, 202
Hi,
Matthias van de Meent writes:
> SELECT toastable_col FROM t1
> WHERE f(t1.toastable_col)
> ORDER BY nonindexed;
Thanks for this example! it's true that the current design requires more
memory to sort since toastable_col is detoasted at the scan stage and it
is output to the sort node. It
On Mon, 4 Dec 2023 at 14:23, wrote:
>
>
> Hi,
>
> Matthias van de Meent writes:
>
> > On Mon, 4 Dec 2023 at 07:56, wrote:
>
> > ..It would also add overhead when
> > we write results to disk, such as spilling merge sorts, hash join
> > spills, or CTE materializations.
> >
> > Could you find a wa
Hi,
Matthias van de Meent writes:
> On Mon, 4 Dec 2023 at 07:56, wrote:
> ..It would also add overhead when
> we write results to disk, such as spilling merge sorts, hash join
> spills, or CTE materializations.
>
> Could you find a way to reduce this memory and IO usage when the value
> is n
On Mon, 4 Dec 2023 at 07:56, wrote:
> 'SELECT f1(toast_col) FROM t;' will apply this code path, but nothing
> gain and nothing lost. Applying this code path only when the toast
> datum is accessed 1+ times needs some extra run-time effort. I don't
> implement this so far, I'd like to see if I mis
Nikita Malakhov writes:
Hi!
>
> 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!
--
Best Regards
Andy Fan
Hi!
There's a view from the other angle - detoast just attributes that are
needed
(partial detoast), with optimized storage mechanics for JSONb. I'm preparing
a patch for it, so maybe the best results could be acquired by combining
these
two techniques.
What do you think?
--
Regards,
Nikita Mala
Currently our code can do lazily detoast by design, for example:
SELECT toast_col FROM t;
SELECT toast_col FROM t ORDER BY b;
SELECT toast_col FROM t join t2 using(c);
it is only detoast at {type}_out function. The benefits includes:
1. The life time of detoast datum is pretty short which is g
14 matches
Mail list logo
