Re: Listen / Notify rewrite

On Thu, Nov 12, 2009 at 3:30 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Couple of questions:
>
> *) is BLCKSZ a hard requirement, that is, coming from the slru
> implementation, or can QUEUE_PAGESIZE be bumped independently of block
> size.

It's the size of slru's pages.

> *) why not make the AsyncQueueEntry divide evenly into BLCKSZ, that
> is, make the whole structure a size that is a multiple of two?  (this
> would make the payload length 'weird')

it's possible and yes, it would make the payload length weird. Also if
we wanted to add further structure members later on (commit time, xid,
notify counter, whatever) we'd have to announce that payload in a new
release cannot have the same length as in a previous one, so I tried
to keep both independent right from the beginning.

> *) is there any downside you see to making the AsyncQueueEntry
> structure exactly BLCKSZ bytes in size?  Are we worried about the
> downsides of spinning the notifications out to disk?

Yes, and also we'd need a lot more page slots to work efficiently and
I fear quite some queue managing overhead (locking). Currently we are
using 4 page slots and can have ~160 notifications mapped into memory.

> *) Is a variable length AsyncQueueEntry possible? (presumably bounded
> by the max page size).  Or does complicate the implementation too
> much?

That's an option to look at, I think it's technically possible, we'd
just need to throw in some more logic but I didnt want to invest too
much effort before we have a clear way to go.

However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.

Joachim