jiaaro

I don't see the source code, where did you find that?

[Edit] Or are you implying that readers should direct an LLM at the entire article and expect an equivalent tool to be produced

Exists is a useful tool that you should certainly know how to use. Whether or not it's faster than distinct depends on the rest of the query. I've optimized queries where distinct is faster than exists. It's been some time, but I think it boils down to the relative sizes of the tables and how many of the exists queries actually find something (and how often they find more than one something).

Also, some databases (like clickhouse) allow for `any` joins which avoid producing duplicate rows. For example:

    select author.*
    from author
    inner any join book on (
        book.author_id = author.id 
        and book.title like 'Book%'
    )

Cool project! But, I wonder how long can a project like this use a Pokemon as their namesake and mascot before you hear from nintendo's lawyers?

Random and round robin partitioning are the configurations being discussed.

The main point of the article is that low message volumes mean you can get unlucky and end up with idle workers when there is still work to be done

The linked article says, in reference to Oracle relocating its HQ to Austin:

> Oracle, which was founded in Santa Clara, Calif., in 1977, later had its headquarters in Redwood City. The software giant, at the time of its move to Texas, said that relocation was to allow a more flexible approach to its workforce

> The company had neither asked for nor received economic incentives from Austin to relocate, said city officials. Nashville pledged $175 million in incentives and the state of Tennessee $65 million to help build the Oracle campus in 2021

The main difference is that you wouldn’t instead drive the whole way instead once you find out the risk. But people do drive the same places they fly

`str(queryset.query)` does not give you executable SQL. Query parameters are not escaped or encoded in that representation of the query. That escaping/interpolation of query parameters is performed by mogrify. I agree the name is odd, and I don't know why they use it other than "transmogrify" being an obscure word for "magically transform".

debug_toolbar and silk are both tools that show you what queries were executed by your running application. They're both good tools, but neither quite solves the problem of giving you the executable SQL for a specific queryset (e.g., in a repl).

If you use postgres, psycopg provides `cursor.mogrify(query, params)` which returns the actual query that will be executed . For example:

    cursor.mogrify(*queryset.query.sql_with_params())

Alternatively, you can set the log level of the `django.db.backends` logger to DEBUG to see all executed queries

On the other hand, these things see a lot more annual miles than consumer vehicles so the payback period should be shorter. I agree though, that probably it would require some kind of government involvement to get broad adoption.

Also, I imagine it's easier to find extra space for batteries in the the trailer than the tractor.

Regenerative breaking seems like a more important improvement though.

Based on the paper Dang linked, it appears that epoxy is involved in all queries to all data stores it coordinates

Does Epoxy use postgres' own transaction ids across datastores? If not, does it implement its own "transaction id horizon" like postgres has so that you can assume all transactions before a certain counter are committed?

I’m not an industry expert either, but ear plugs don’t block sound taking other paths to the ear drum like bone conduction. The mix knob on this limiter can’t be turned to 100%