ruby.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
If you are interested in the Ruby programming language, come join us! Tell us about yourself when signing up. If you just want to join Mastodon, another server will be a better place for you.

Administered by:

Server stats:

1.1K
active users

Benoit

I was quite impressed with the impact of specifying the order column (when there is limit) in your index in

> An important special case is ORDER BY in combination with LIMIT n: an explicit sort will have to process all the data to identify the first n rows, but if there is an index matching the ORDER BY, the first n rows can be retrieved directly, without scanning the remainder at all.

postgresql.org/docs/current/in

PostgreSQL Documentation11.4. Indexes and ORDER BY11.4. Indexes and ORDER BY In addition to simply finding the rows to be returned by a query, an index may …

@benoit this reminds me of a fun mongodb "feature". When you had both a sort and a limit, it would not return correct results. We had to ask the db for the whole sorted result set, and then only keep the top ones.

@clementd @benoit additional fun one. How many APM providers out there have a query system that works like this and have a forced limit due to pagination.

Spoiler: yes the big ones you think of do.

@benoit Data ordering is under appreciated in general because so many applications/domains get it "for free”. Data arrives in an order that is very close to how it is consumed.

You really notice this when your distributed database destroys this order during a shuffle. Suddenly your table is 2x larger on disk! But order preservation is actually really hard and opens you up to terrible skew problems.

@joeharris76 Appreciate your comment :)