Re: can we publish a aset interface?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: can we publish a aset interface?
Date: 2010-09-07 14:40:33
Message-ID: 9702.1283870433@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> I would to use a special memory context for shared data (based on
> mmap) and I like impementation of aset. There is only one difference -
> aset is based on malloc and I would to use a mmap.

> malloc() is used in AllocSetContextCreate and AllocSetAlloc. These
> procedures should be overwritten, but other code and data structures
> can be used. This step can be useful for previous discuss about some
> more comfortable maintaining of shared memory.

> What do you think about?

If you're proposing factoring aset.c into two levels, I don't think so.
That code is already a tremendous performance hot-spot and introducing
any more inefficiency into it doesn't seem like a good idea. Especially
not for shared memory allocation, which is a feature that still has
no buy-in. Also, you'd need to do more than just replace malloc: you'd
need to add locking capability. That would make the code even uglier,
and slower, if it has to support locking or no locking dynamically.

Use the mcxt.c switch. That's what it's there for.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-09-07 14:47:27 Re: Synchronous replication - patch status inquiry
Previous Message Magnus Hagander 2010-09-07 14:32:53 Re: git: uh-oh