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,
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
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
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
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
Damir Belyalov writes:
> Here is a very straw-man-level sketch of what I think might work.
> The option to COPY FROM looks something like
>
>ERRORS TO other_table_name (item [, item [, ...]])
>
> I tried to implement the patch using a table and came across a number of
> questions.
zhihuifan1...@163.com writes:
Hi,
Here is the v3, the mainly changes is it maintains the UniqueKey on
joinrel level, which probabaly is the most important part of this
feature. It shows how the UnqiueKey on joinrel is generated and how it
is discarded due to non-interesting-uniquekey and also sh
Tom Lane writes:
> Daniel Gustafsson writes:
>>> On 8 Nov 2023, at 19:18, Tom Lane wrote:
>>> I think an actually usable feature of this sort would involve
>>> copying all the failed lines to some alternate output medium,
>>> perhaps a second table with a TEXT column to receive the original
>
jian he writes:
> On Fri, Oct 20, 2023 at 4:33 PM wrote:
>>
>>
>> > i did some simple tests using text data type.
>> >
>> > it works with the primary key, not with unique indexes.
>> > it does not work when the column is unique, not null.
>> >
>> > The following is my test.
>>
>> Can you simpl
Chapman Flack writes:
(This is Andy Fan and I just switch to my new email address).
Hi Chap,
Thanks for alway keep an eye on this!
> Adding this comment via the CF app so it isn't lost, while an
> improperly-interpreted-DKIM-headers issue is still preventing me from
> mailing directly to -hac
> i did some simple tests using text data type.
>
> it works with the primary key, not with unique indexes.
> it does not work when the column is unique, not null.
>
> The following is my test.
Can you simplify your test case please? I can't undertand what "doesn't
work" mean here and for which
jian he writes:
Hi jian,
> hi.
> After `git am`, I still cannot build.
>
> ../../Desktop/pg_sources/main/postgres/src/backend/optimizer/path/uniquekey.c:125:45:
> error: variable ‘var’ set but not used
> [-Werror=unused-but-set-variable]
> 125 | Var*var
Hi,
David and I had worked the uniquekey stuff since 2020[1], and later it
is blocked by the NULL values stuff. Now the blocker should be removed
by Var.varnullingrels, so it is time to work on this again. During the
past 3 years, we have found more and more interesting usage of it.
Here is a d
13 matches
Mail list logo
