On Fri, 14 Jul 2023 at 18:53, Melih Mutlu wrote:
> David Rowley , 13 Tem 2023 Per, 08:04 tarihinde şunu
> yazdı:
>>
>> I looked at your v2 patch. The only thing that really looked wrong
>> were the (Size) casts in the context creation functions. These should
>> have been casts to uint32 rather
Hi David,
David Rowley , 13 Tem 2023 Per, 08:04 tarihinde şunu
yazdı:
> I looked at your v2 patch. The only thing that really looked wrong
> were the (Size) casts in the context creation functions. These should
> have been casts to uint32 rather than Size. Basically, all the casts
> do is say
On Tue, 11 Jul 2023 at 02:41, Melih Mutlu wrote:
> > - Afaics AllocSet->keeper is unnecessary these days, as it is always
> > allocated
> > together with the context itself. Saves 8 bytes.
>
> This seemed like a safe change and removed the keeper field in
> AllocSet and Generation contexts. It
Hi,
Thanks for your comments.
Tom Lane , 28 Haz 2023 Çar, 13:59 tarihinde şunu yazdı:
>
> David Rowley writes:
> > Perhaps it's ok to leave the context creation functions with Size
> > typed parameters and then just Assert the passed-in sizes are not
> > larger than 1GB within the context
Hi,
On 2023-06-29 11:58:27 +0200, Tomas Vondra wrote:
> On 6/29/23 01:34, Andres Freund wrote:
> > On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
> >> Yeah. FWIW I was interested what the patch does in practice, so I
> >> checked what pahole says about impact on struct sizes:
> >>
> >>
On 6/29/23 01:34, Andres Freund wrote:
> Hi,
>
> On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
>> Yeah. FWIW I was interested what the patch does in practice, so I
>> checked what pahole says about impact on struct sizes:
>>
>> AllocSetContext 224B -> 208B (4 cachelines)
>>
On Thu, 29 Jun 2023 at 09:26, Tomas Vondra
wrote:
> AllocSetContext 224B -> 208B (4 cachelines)
> GenerationContext 152B -> 136B (3 cachelines)
> SlabContext 200B -> 200B (no change, adds 4B hole)
>
> Nothing else changes, AFAICS.
I don't think a lack of a reduction in the number
Hi,
On 2023-06-28 17:56:55 -0400, Tom Lane wrote:
> Tomas Vondra writes:
> > ... 4B is tiny compared to what we waste due to the doubling.
>
> Yeah. I've occasionally wondered if we should rethink aset.c's
> "only power-of-2 chunk sizes" rule. Haven't had the bandwidth
> to pursue the idea
Hi,
On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
> Yeah. FWIW I was interested what the patch does in practice, so I
> checked what pahole says about impact on struct sizes:
>
> AllocSetContext 224B -> 208B (4 cachelines)
> GenerationContext 152B -> 136B (3 cachelines)
> SlabContext
Tomas Vondra writes:
> ... 4B is tiny compared to what we waste due to the doubling.
Yeah. I've occasionally wondered if we should rethink aset.c's
"only power-of-2 chunk sizes" rule. Haven't had the bandwidth
to pursue the idea though.
regards, tom lane
On 6/28/23 12:59, Tom Lane wrote:
> David Rowley writes:
>> Perhaps it's ok to leave the context creation functions with Size
>> typed parameters and then just Assert the passed-in sizes are not
>> larger than 1GB within the context creation function.
>
> Yes, I'm strongly opposed to not using
David Rowley writes:
> Perhaps it's ok to leave the context creation functions with Size
> typed parameters and then just Assert the passed-in sizes are not
> larger than 1GB within the context creation function.
Yes, I'm strongly opposed to not using Size/size_t in the mmgr APIs.
If we go that
On Wed, 28 Jun 2023 at 20:13, Peter Eisentraut wrote:
> size_t (= Size) is the correct type in C to store the size of an object
> in memory. This is partially a self-documentation issue: If I see
> size_t in a function signature, I know what is intended; if I see
> uint32, I have to wonder what
In memory contexts, block and chunk sizes are likely to be limited by
some upper bounds. Some examples of those bounds can be
MEMORYCHUNK_MAX_BLOCKOFFSET and MEMORYCHUNK_MAX_VALUE. Both values are
only 1 less than 1GB.
This makes memory contexts to have blocks/chunks with sizes less than
1GB.
Hi hackers,
In memory contexts, block and chunk sizes are likely to be limited by
some upper bounds. Some examples of those bounds can be
MEMORYCHUNK_MAX_BLOCKOFFSET and MEMORYCHUNK_MAX_VALUE. Both values are
only 1 less than 1GB.
This makes memory contexts to have blocks/chunks with sizes less
15 matches
Mail list logo
