I wrote:
> I think that we'd probably be better off fixing the root performance issue
> than adding semantic complexity to bypass it. ...
> Accordingly, I looked into making a hash table when there are more than
> a small number of notifications pending, and attached is a lightly-tested
> version
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> Still no hash table fallback is implemented, so this is *not* a
> performance improvement. Only a little more flexibility.
I think that we'd probably be better off fixing the root performance issue
than adding semantic complexity to bypass it.
Thank you.
Here is my latest attempt, with actual syntax error handling.
Also, the syntax is updated to what Tom Lane suggested in other
thread (with another variant of the same thing, from Julien Demoor)
NOTIFY [ ( option [, ...] ) ] channel [ , payload ]
Still no hash table fallback is
On Fri, Mar 8, 2019 at 1:37 PM Filip Rembiałkowski
wrote:
> See attached patch... I'm ready to work on so it can get merged in the next
> CF.
Hi Filip,
Seen on Travis:
async... FAILED 126 ms
Looks like the new error isn't being raised for invalid send mode?
Thanks for all the input.
Finally I found time and motivation to revive this.
See attached patch... I'm ready to work on so it can get merged in the next CF.
On Thu, Mar 17, 2016 at 12:44 AM David Steele wrote:
>
> On 3/11/16 1:46 PM, David Steele wrote:
> > Hi Filip,
> >
> > On 2/20/16 8:00
