| From: | Andrew Chernow <ac(at)esilo(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org, Andrew Chernow <andrew(at)esilo(dot)com> |
| Subject: | Re: Listen / Notify rewrite |
| Date: | 2009-11-13 20:43:20 |
| Message-ID: | 4AFDC4E8.1020004@esilo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> My original intention was to have the queue as a circular buffer where
> the size of the entries was variable, but possibly bounded. Certainly
> using fixed length records of large size seems somewhat wasteful.
>
Maybe we should do away with 'spill to disk' all together and either
hard-code an overflow behavior or make it a knob. Possible overflow
behaviors could be block until space is available, throw an error or
silently drop it.
Can the size of the shared memory segment for notifications be
configurable? That would allow those with large payloads or a huge
number of notifications to bump memory to avoid overflow cases. By
removing the disk and making shmem usage configurable, I think the
notify system would be flexible and could scale nicely.
Another added benefit is the payload limit can be much higher than
previously considered, because memory/performance concerns are now in
the hands of the DBA.
> Incidentally, I'd like to thank Joachim personally for having done this
> work,
+1
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zdenek Kotala | 2009-11-13 20:58:56 | [PATCH] dtrace probes for memory manager |
| Previous Message | David E. Wheeler | 2009-11-13 20:38:15 | Re: CommitFest 2009-11: Almost done with initial assignments |