From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: rethinking dense_alloc (HashJoin) as a memory context |
Date: | 2016-07-18 14:19:18 |
Message-ID: | CAM-w4HPhHCTA==pNYBGtVnX8QXEmfPrsKqcJWivDdOBZd+fZcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 17, 2016 at 1:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>On Wed, Jul 13, 2016 at 4:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
>> fields becoming specific to particular mcxt implementations.
>
> I think that would be worth doing. It's not perfect, and the extra 8
> (or 4) bytes per chunk certainly do matter.
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 everything in a contiguous
block to recognize pointers and return the memory context just by the
range the pointer lies in.
There could be optimizations like if the leading points point to a
structure with a decently large magic number then assume it's a valid
header to avoid the cost of checking with lots of allocators. But I'm
imagining that the list of allocators in use concurrenlty will be
fairly small so it might not even be necessary.
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-18 14:28:17 | Re: DO with a large amount of statements get stuck with high memory consumption |
Previous Message | Merlin Moncure | 2016-07-18 14:12:13 | Re: DO with a large amount of statements get stuck with high memory consumption |