Hi,
On 2021-08-31 15:06:32 -0400, John Naylor wrote:
> Were you thinking in terms of passing the type oid in parameters, like this?
>
> HeapTuple
> SearchCatCache1(CatCache *cache, Datum v1, Oid t1)
> {
> return SearchCatCacheInternal(cache, 1, v1, t1, 0, 0, 0, 0, 0, 0);
> }
>
> And then Catal
On Fri, Aug 27, 2021 at 3:42 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-08-19 19:10:37 -0400, John Naylor wrote:
> > I've made a small step in this direction in the attached. It uses a
> > template approach to generate type-specific SearchCatCache* functions,
for
> > now only the 4-key ones. Sinc
Hi,
On 2021-08-19 19:10:37 -0400, John Naylor wrote:
> I've made a small step in this direction in the attached. It uses a
> template approach to generate type-specific SearchCatCache* functions, for
> now only the 4-key ones. Since there's only a few of those, it's manageable
> to invoke the temp
On Thu, Aug 5, 2021 at 4:12 PM Andres Freund wrote:
> I have wondered before whether we should have syscache definitions
generate
> code specific to each syscache definition. I do think that'd give a good
bit
> of performance boost. But I don't see a trivial way to get there without
> notational o
OK, here is a hackish WIP to see if we get anywhere with the L1 concept:
0001 is extracted from a patch from Horiguchi-san to remove the "dead" flag
0002 adds the large bucket, but doesn't use it for anything
0003 uses the new bucket for the L1 cache
0004 changes when to rehash
0005 is Horiguchi-s
On Thu, Aug 5, 2021 at 4:12 PM Andres Freund wrote:
> I have wondered before whether we should have syscache definitions
generate
> code specific to each syscache definition. I do think that'd give a good
bit
> of performance boost. But I don't see a trivial way to get there without
> notational o
Hi,
On Thu, Aug 5, 2021, at 22:20, Yura Sokolov wrote:
> Andres Freund писал 2021-08-06 06:49:
> > Hi,
> >
> > On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
> >> Why don't use simplehash or something like that? Open-addressing
> >> schemes
> >> show superior cache locality.
> >
> > I though
Andres Freund писал 2021-08-06 06:49:
Hi,
On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
Why don't use simplehash or something like that? Open-addressing
schemes
show superior cache locality.
I thought about that as well - but it doesn't really resolve the
question of
what we want to sto
Hi,
On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
> Why don't use simplehash or something like that? Open-addressing schemes
> show superior cache locality.
I thought about that as well - but it doesn't really resolve the question of
what we want to store in-line in the hashtable and what not
Andres Freund писал 2021-08-05 23:12:
Hi,
On 2021-08-05 12:27:49 -0400, John Naylor wrote:
On Wed, Aug 4, 2021 at 3:44 PM Andres Freund
wrote:
> On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> > typedef struct cc_bucket
> > {
> > uint32 hashes[4];
> > catctup *ct[4];
> > dlist_head;
Hi,
On 2021-08-05 12:27:49 -0400, John Naylor wrote:
> On Wed, Aug 4, 2021 at 3:44 PM Andres Freund wrote:
> > On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> > > typedef struct cc_bucket
> > > {
> > > uint32 hashes[4];
> > > catctup *ct[4];
> > > dlist_head;
> > > };
> >
> > I'm not con
On Wed, Aug 4, 2021 at 3:44 PM Andres Freund wrote:
> On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> > typedef struct cc_bucket
> > {
> > uint32 hashes[4];
> > catctup *ct[4];
> > dlist_head;
> > };
>
> I'm not convinced that the above the right idea though. Even if the hash
> matches, y
Hi,
On 2021-08-04 12:39:29 -0400, John Naylor wrote:
> CPU caches have multiple levels, so I had an idea to use that concept in
> the syscaches.
I do think we loose a good bit to syscache efficiency in real workloads, so I
think it's worth investing time into it.
However:
> Imagine if catcache
13 matches
Mail list logo
