Hello All,
I have the following table:
postgres=# \d so_rum;
Table "public.so_rum"
Column | Type | Collation | Nullable | Default
---+-+---+--+-
id| integer
- Mensagem original -
De: "David Rowley"
Para: "luis.roberto"
Cc: "FabrÃzio de Royes Mello" , "pgsql-general"
Enviadas: Domingo, 12 de julho de 2020 5:29:08
Assunto: Re: Join optimization
On Sun, 12 Jul 2020 at 06:59, wrote:
>
> I'm sorry for the bad example.
>
> Here is another, wi
On Sat, Jul 11, 2020 at 10:44 AM Brian Dunavant wrote:
> One aspect is if there is no one listening when a notify happens, the
> message is lost (e.g. no durability). If this is important to you, it can
> be addressed by writing the messages to a table as well when you NOTIFY,
> and the listene
Good to know about potential performance problems. I don't plan to have
more than 5 hosts. Also, good to know about MQTT.
On Sun, Jul 12, 2020 at 8:52 AM Andrew Smith wrote:
> On Sun, 12 Jul 2020 at 21:39, Rita wrote:
>
>> Thats good to know. Are there some standard patterns or best practices
Andrew Smith writes:
> A couple of years ago I started looking into listen/notify in PG10 and
> found that the throughput decreased quite a bit as I added more and more
> listeners. Given the number of apps I needed to have listening and the
> number of messages that I expected to be consuming, I
On Sun, 12 Jul 2020 at 21:39, Rita wrote:
> Thats good to know. Are there some standard patterns or best practices I
> should follow when using messaging and with listen/notify?
>
> On Sat, Jul 11, 2020 at 1:44 PM Brian Dunavant wrote:
>
>> One aspect is if there is no one listening when a notif
Thats good to know. Are there some standard patterns or best practices I
should follow when using messaging and with listen/notify?
On Sat, Jul 11, 2020 at 1:44 PM Brian Dunavant wrote:
> One aspect is if there is no one listening when a notify happens, the
> message is lost (e.g. no durability)
On Sun, 12 Jul 2020 at 06:59, wrote:
>
> I'm sorry for the bad example.
>
> Here is another, with some data on PG:
> https://dbfiddle.uk/?rdbms=postgres_13&fiddle=ccfd1c4fa291e74a6db9db1772e2b5ac
> and Oracle:
> https://dbfiddle.uk/?rdbms=oracle_18&fiddle=21a98f499065ad4e2c35ff4bd1487e14.
I
