Who here considers themselves a Drizzle expert?

0 reply

0 recast

0 reaction

The evolution of time series databases https://www.youtube.com/watch?v=r4LkaPkxang&t=4648s

0 reply

0 recast

1 reaction

TIL I had a PostgreSQL database query where block number was float instead of an integer. (This would not ever happen e.g. in JavaScript, but this time we were using the best programming language in the world. Python). Instead of taking under-milliseconds the query took more than ten minutes. I'm not sure if this is because the index match is only for integers, or if PostgreSQL is doing some other unusual behaviour. But this was damned hard to find.

2 replies

0 recast

1 reaction

OrioleDB is an interesting PG extension that offers a different storage system than the standard tuple heap. But that's not why I'm Casting; there blog is a treasure trove of PG knowledge: https://www.orioledb.com/blog

0 reply

0 recast

4 reactions

wow! I didn't realize AWS has a mechanism for taking consistent snapshots across EBS volumes. https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/

0 reply

0 recast

1 reaction

Is there a user interface available where I can input my database URL and then add events to the database?

3 replies

0 recast

1 reaction

Fascinating to think about optimizing loops for CPUs. I wonder if PG's numeric additions could benefit from a more branchless approach https://github.com/postgres/postgres/blob/4f15759bdcddd23e874526a6b2c0ff86e0beb042/src/interfaces/ecpg/pgtypeslib/numeric.c#L637-L754 https://15721.courses.cs.cmu.edu/spring2023/slides/06-execution.pdf

0 reply

0 recast

3 reactions

Quick PG debugging story. And a great blog post about the Postgres null byte situation. Seems to be a common rough edge. https://www.commandprompt.com/blog/null-characters-workarounds-arent-good-enough/ https://warpcast.com/typedarray.eth/0x761b14a8

0 reply

0 recast

7 reactions

UPDATE heavy workloads on PG are known to scatter rows around on pages which may increase IO when scanning many rows in a single query. Unless you are getting 100% HOT updates (most aren't). To solve this in the past, I've used CLUSTER -- which isn't great because it requires a lock and takes a long time. It's almost unusable. pg_repack solves this by doing online re-clustering and storage reclamation. https://reorg.github.io/pg_repack/

1 reply

0 recast

7 reactions

https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html Spoiler: MVCC This also helps bring awareness to the impact of UPDATE heavy workloads on PG

0 reply

0 recast

0 reaction

A rebuttal to Uber’s PG/MySQL paper. Keep in mind, PG has changed since this discussion. A lot of the replication issues are long since put to rest. The storage sub-systems are the interesting point of difference between these systems. MYSQL’s indexes point to primary keys instead of a CTID. An update to a MySQL row will have same storage location but PG will be a new CTID/page — unless it was a Heap Only Tuple (HOT) update. But this means PG can reduce IO for queries. As with anything, it’s always a tradeoff. However, database systems in particular are especially sensitive to workload details. The tradeoffs really matter! https://thebuild.com/presentations/uber-perconalive-2017.pdf

1 reply

1 recast

9 reactions

Using stored procedures for complex query patterns makes sense, but I don't have an intuition for the kind of query complexity necessary before seeing tangible benefits switching from prepared statements. Glad someone is experimenting! https://github.com/pg-nano/pg-nano/

1 reply

8 recasts

31 reactions

so, how many table can postgres hold? pg:

1 reply

1 recast

4 reactions

initial thoughts on AWS DSQL 1. PG compatible (pg is dominant at this point) 2. Most of the article talked about HA 3. AWS has a proprietary, internal distributed transaction log service that is supposedly the most important piece of AWS and everything in AWS depends on it. Hope that teams makes 10M annual tc each. 4. It depresses me to think that the future of compute and storage is: run it on aws It's really neat to think about having a network storage layer that can support many database frontends. this seems like the future. Neon et al. are moving in this direction. Also something that Stonebraker has been talking about for a while now. https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/

4 replies

4 recasts

15 reactions

https://avi.im/blag/2024/zero-disk-architecture/ This is a really neat idea. Low latency, CAS, and append are killer S3 features. But kind of dystopian to think that all our data is owned and operated by a single US company. WDYT?

1 reply

1 recast

3 reactions