LISTEN / NOTIFYis a feature that enables users to listen to what goes on in the database. It is one of the oldest functionalities in PostgreSQL and is still widely used. The main question is: What is the purpose of the asynchronous query interface (LISTEN / NOTIFY), and what is it good for? The basic idea is to avoid polling.
Source: LISTEN / NOTIFY: Automatic client notification in PostgreSQL, an article by Hans-Jürgen Schönig.
Here are some of the ways you can discover your data processing jobs are too slow:
- Jobs start getting killed when they hit timeouts.
- Customers start complaining about slow or failed jobs.
- Your cloud computing bill is twice what it was last month.
While these notification mechanisms do work, it’s probably best not to rely on them. Life is easier when jobs finish successfully, customers are happy, and you have plenty of money left over in your budget.
That means you want to identify unexpected slowness or high memory usage before the situation get that bad. The sooner you can identify performance problems, the sooner you can fix them.
So how can you identify inefficient tasks in your data pipeline or workflow? Let’s find out!
Source: Find slow data processing tasks (before your customers do), an article by Itamar Turner-Trauring.
Did you know that DOM elements with IDs are accessible in JavaScript as global variables? It’s one of those things that’s been around, like, forever but I’m really digging into it for the first time.
Source: Named Element IDs Can Be Referenced as JavaScript Globals, an article by Matteo Mazzarolo.