I have prepared a patch to backends/commands/async,c to speed up
duplicate elimination. rdtsc timing results are sent back via ereport.
*** a/src/backend/commands/async.c
--- b/src/backend/commands/async.c
***
*** 326,337 typedef struct Notification
--- 326,353
{
char
Tom Lane schrieb:
> Hardy Falk writes:
>>> Well, you didn't add any code, so it's hard to say... Simple ways of
>>> doing what I think you describe will remove the queue's order. Do you
>>> preserve the ordering guarantees?
>
>> Yes, the order is preserved.
>> I didn't remove the the original lis
Hardy Falk writes:
>> Well, you didn't add any code, so it's hard to say... Simple ways of
>> doing what I think you describe will remove the queue's order. Do you
>> preserve the ordering guarantees?
> Yes, the order is preserved.
> I didn't remove the the original list code.
> The tree is just
Hi,
On 2014-02-08 19:28:56 +0100, Hardy Falk wrote:
> > Well, you didn't add any code, so it's hard to say... Simple ways of
> > doing what I think you describe will remove the queue's order. Do you
> > preserve the ordering guarantees?
> >
> > Greetings,
> >
> > Andres Freund
> >
> Yes, the or
> Well, you didn't add any code, so it's hard to say... Simple ways of
> doing what I think you describe will remove the queue's order. Do you
> preserve the ordering guarantees?
>
> Greetings,
>
> Andres Freund
>
Yes, the order is preserved.
I didn't remove the the original list code.
The tree
Hi,
On 2014-02-08 18:56:41 +0100, Hardy Falk wrote:
> I know that it is not a big problem for most users, but allowing a very
> large number of notifications while using linear search is a bit dumb.
> I can fix this with a very small modification to
> struct Notification:
> {
> char *channel
I know that it is not a big problem for most users, but allowing a very
large number of notifications while using linear search is a bit dumb.
I can fix this with a very small modification to
struct Notification:
{
char *channel ;
char *payload ;
uint32 hash ;
struct
