Tomas Vondra writes:
> On 2/25/24 17:29, Tom Lane wrote:
>> Yeah. Also: once we had such an idea, it'd be very tempting to apply
>> it to other frequently-reset contexts like the executor's per-tuple
>> evaluation contexts. I'm not quite prepared to argue that
>> MemoryContextReset should just a
On 2/25/24 17:29, Tom Lane wrote:
> Tomas Vondra writes:
>> On 2/25/24 00:07, Tom Lane wrote:
>>> ... I'm not sure if it'd be worth extending
>>> the mcxt.c API to provide something like "MemoryContextResetIfBig",
>>> with some internal rule that would be cheap to apply like "reset
>>> if we h
Tomas Vondra writes:
> On 2/25/24 00:07, Tom Lane wrote:
>> ... I'm not sure if it'd be worth extending
>> the mcxt.c API to provide something like "MemoryContextResetIfBig",
>> with some internal rule that would be cheap to apply like "reset
>> if we have any non-keeper blocks".
> I think Memor
On 2/25/24 00:07, Tom Lane wrote:
> I wrote:
>> Tomas Vondra writes:
>>> On 2/19/24 16:45, Tom Lane wrote:
Tomas Vondra writes:
> For example, I don't think we expect selectivity functions to allocate
> long-lived objects, right? So maybe we could run them in a dedicated
> memory
I wrote:
> Tomas Vondra writes:
>> On 2/19/24 16:45, Tom Lane wrote:
>>> Tomas Vondra writes:
For example, I don't think we expect selectivity functions to allocate
long-lived objects, right? So maybe we could run them in a dedicated
memory context, and reset it aggressively (after
Hi!
On 20.02.2024 07:41, Andrei Lepikhov wrote:
On 20/2/2024 04:51, Tom Lane wrote:
Tomas Vondra writes:
On 2/19/24 16:45, Tom Lane wrote:
Tomas Vondra writes:
For example, I don't think we expect selectivity functions to
allocate
long-lived objects, right? So maybe we could run them in a
On 20/2/2024 04:51, Tom Lane wrote:
Tomas Vondra writes:
On 2/19/24 16:45, Tom Lane wrote:
Tomas Vondra writes:
For example, I don't think we expect selectivity functions to allocate
long-lived objects, right? So maybe we could run them in a dedicated
memory context, and reset it aggressivel
On 19/2/2024 20:47, Tomas Vondra wrote:
On 9/8/23 07:11, Lepikhov Andrei wrote:
Just for comparison, without partitioning:
elems 1 1E1 1E2 1E3 1E4
master: 12kB14kB37kB266kB 2.5MB
patched:12kB11.5kB 13kB24kB
Tomas Vondra writes:
> On 2/19/24 16:45, Tom Lane wrote:
>> Tomas Vondra writes:
>>> For example, I don't think we expect selectivity functions to allocate
>>> long-lived objects, right? So maybe we could run them in a dedicated
>>> memory context, and reset it aggressively (after each call).
>>
On 2/19/24 16:45, Tom Lane wrote:
> Tomas Vondra writes:
>> Considering there are now multiple patches improving memory usage during
>> planning with partitions, perhaps it's time to take a step back and
>> think about how we manage (or rather not manage) memory during query
>> planning, and see i
Tomas Vondra writes:
> Considering there are now multiple patches improving memory usage during
> planning with partitions, perhaps it's time to take a step back and
> think about how we manage (or rather not manage) memory during query
> planning, and see if we could improve that instead of an in
On 9/8/23 07:11, Lepikhov Andrei wrote:
>
>
> On Wed, Sep 6, 2023, at 8:09 PM, Ashutosh Bapat wrote:
>> Hi Lepikhov,
>>
>> Thanks for using my patch and I am glad that you found it useful.
>>
>> On Mon, Sep 4, 2023 at 10:56 AM Lepikhov Andrei
>> wrote:
>>>
>>> Hi, hackers,
>>>
>>> Looking at
On Wed, Sep 6, 2023, at 8:09 PM, Ashutosh Bapat wrote:
> Hi Lepikhov,
>
> Thanks for using my patch and I am glad that you found it useful.
>
> On Mon, Sep 4, 2023 at 10:56 AM Lepikhov Andrei
> wrote:
>>
>> Hi, hackers,
>>
>> Looking at the planner behaviour with the memory consumption patch [1]
Hi Lepikhov,
Thanks for using my patch and I am glad that you found it useful.
On Mon, Sep 4, 2023 at 10:56 AM Lepikhov Andrei
wrote:
>
> Hi, hackers,
>
> Looking at the planner behaviour with the memory consumption patch [1], I
> figured out that arrays increase memory consumption by the optim
On Mon, Sep 4, 2023 at 3:49 PM Lepikhov Andrei
wrote:
>
> > + Const *c = makeConst(nominal_element_type,
> > + -1,
> > + nominal_element_collation,
> > + elmlen,
> > + elem_values[i],
> > + elem_nulls[i],
> > + elmbyval);
> > +
> > + args = list_make2(leftop, c);
> > if (is_join_clause)
> > s2
On Mon, Sep 4, 2023, at 3:37 PM, Dilip Kumar wrote:
> On Mon, Sep 4, 2023 at 11:58 AM Lepikhov Andrei
> wrote:
>>
>> Hi, hackers,
>>
>> Looking at the planner behaviour with the memory consumption patch [1], I
>> figured out that arrays increase memory consumption by the optimizer
>> signific
On Mon, Sep 4, 2023 at 11:58 AM Lepikhov Andrei
wrote:
>
> Hi, hackers,
>
> Looking at the planner behaviour with the memory consumption patch [1], I
> figured out that arrays increase memory consumption by the optimizer
> significantly. See init.sql in attachment.
> The point here is that the p
Hi, hackers,
Looking at the planner behaviour with the memory consumption patch [1], I
figured out that arrays increase memory consumption by the optimizer
significantly. See init.sql in attachment.
The point here is that the planner does small memory allocations for each
element during estimat
18 matches
Mail list logo
