On Mon, Jul 18, 2016 at 7:56 AM, Robert Haas wrote:
> The test case I used previously was an external sort, which does lots
> of retail pfrees. Now that we've mostly abandoned replacement
> selection, there will be many fewer pfrees while building runs, I
> think, but
On Mon, Jul 18, 2016 at 10:19 AM, Greg Stark wrote:
> On Sun, Jul 17, 2016 at 1:55 PM, Robert Haas wrote:
>>On Wed, Jul 13, 2016 at 4:39 PM, Tom Lane wrote:
>>> I wonder whether we could compromise by reducing the minimum "standard
>>>
Greg Stark writes:
> I wonder if we could go further. If we don't imagine having a very
> large number of allocators then we could just ask each one in turn if
> this block is one of theirs and which context it came from. That would
> allow an allocator that just allocated
On Sun, Jul 17, 2016 at 1:55 PM, Robert Haas wrote:
>
>On Wed, Jul 13, 2016 at 4:39 PM, Tom Lane wrote:
>>
>> I wonder whether we could compromise by reducing the minimum "standard
>> chunk header" to be just a pointer to owning context, with the other
On Wed, Jul 13, 2016 at 4:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
>> wrote:
>> What's not clear to me is to what extent slowing down pfree is an
>> acceptable price for
Andres Freund writes:
> On 2016-07-13 16:39:58 -0400, Tom Lane wrote:
>> I think there's a lot, but I'm afraid most of them are in contexts
>> (pun intended) where aset.c already works pretty well, ie it's a
>> short-lived context anyway.
> FWIW, hacking up the aset/mcxt.c to
On 2016-07-13 16:39:58 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
> > wrote:
> > What's not clear to me is to what extent slowing down pfree is an
> > acceptable price for improving the
Robert Haas writes:
> On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
> wrote:
> What's not clear to me is to what extent slowing down pfree is an
> acceptable price for improving the behavior in other ways. I wonder
> how many of the pfree
On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
wrote:
> I think the MemoryContext API may not be right abstraction for this.
+1. The MemoryContext API is little short of an absolute bar to
implementing an allocator that works significantly differently than
aset.c,
On 07/13/2016 07:37 PM, Tom Lane wrote:
Peter Geoghegan writes:
On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
wrote:
In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
his dislike of dense_alloc. I kinda agree with him
Andres Freund writes:
> On 2016-07-13 13:37:55 -0400, Tom Lane wrote:
>> We already know that
>> that code has performance issues, cf bug #14231, so I suspect there's
>> a redesign in its future anyway.
> Note that it's not the slab allocators that is having problems, it's
>
On 2016-07-13 13:37:55 -0400, Tom Lane wrote:
> I wonder though if we don't already have another similar use-case in
> the ad-hoc "slab allocators" in reorderbuffer.c.
That seems to call more for a general slab allocator design, than for
something like here. After all, there's plenty of freeing
Peter Geoghegan writes:
> On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
> wrote:
>> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
>> his dislike of dense_alloc. I kinda agree with him that introducing "local
>>
On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra
wrote:
> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced
> his dislike of dense_alloc. I kinda agree with him that introducing "local
> allocators" may not be the best idea, and as dense_alloc
Hi,
In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom
voiced his dislike of dense_alloc. I kinda agree with him that
introducing "local allocators" may not be the best idea, and as
dense_alloc was introduced by me I was playing with the idea to wrap
this into a regular
15 matches
Mail list logo