Newest at the top
| 2024-09-30 01:27:10 +0200 | Typedfern | (~Typedfern@2a02:9130:9c34:14e4:d11e:8149:a19f:6793) |
| 2024-09-30 01:21:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-30 01:20:13 +0200 | <geekosaur> | whoops, missed |
| 2024-09-30 01:20:07 +0200 | <geekosaur> | (also, re "Categorical Databases", I'm a programmer/sysadmin who's picked up a very little bit of abstract mathematics from hanging out in here; I expect that paper would be gobbledygook to me) |
| 2024-09-30 01:19:24 +0200 | andrewboltachev | (~andrey@178.141.123.3) (Quit: Leaving.) |
| 2024-09-30 01:16:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-09-30 01:10:53 +0200 | Typedfern | (~Typedfern@2a02:9130:9c34:14e4:99e7:1e2d:3a90:e394) (Ping timeout: 265 seconds) |
| 2024-09-30 01:06:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-30 01:01:28 +0200 | deepfire | (~user@80.92.100.69) (Remote host closed the connection) |
| 2024-09-30 01:00:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-09-30 00:54:12 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 276 seconds) |
| 2024-09-30 00:50:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-30 00:46:38 +0200 | xsarnik | (xsarnik@lounge.fi.muni.cz) (The Lounge - https://thelounge.chat) |
| 2024-09-30 00:45:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-09-30 00:44:55 +0200 | <geekosaur> | but that was around when the open source community picked up postgres, ripped out the research-quality QUEL engine, and started building a production-quality SQL engine to replace it |
| 2024-09-30 00:44:51 +0200 | <andrewboltachev> | wow |
| 2024-09-30 00:44:17 +0200 | <geekosaur> | I don't actually do databases any more (since 1996) |
| 2024-09-30 00:43:02 +0200 | <andrewboltachev> | geekosaur: and have you seen "Categorical databases"? And if yes, do you think it brings anything useful |
| 2024-09-30 00:43:01 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2024-09-30 00:41:14 +0200 | <andrewboltachev> | geekosaur: do you use esqueleto or sth? |
| 2024-09-30 00:39:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-30 00:39:02 +0200 | <andrewboltachev> | geekosaur: I sometimes optimize ORM calls :D (e.g. call 1 time instead of N) |
| 2024-09-30 00:38:56 +0200 | Eoco | (~ian@128.101.131.218) Eoco |
| 2024-09-30 00:38:47 +0200 | <geekosaur> | (sorry, my inner db wonk is showing 🙂 ) |
| 2024-09-30 00:37:52 +0200 | <geekosaur> | it's doing a lot of bookkeeping to optimize sql-style queries, if you do nosql with it that's all wasted |
| 2024-09-30 00:37:48 +0200 | Eoco | (~ian@128.101.131.218) (Quit: WeeChat 4.4.2) |
| 2024-09-30 00:37:34 +0200 | <andrewboltachev> | ah |
| 2024-09-30 00:37:12 +0200 | <geekosaur> | the higher overhead means it's usually not that great at them. tbh I'd use sqlite at that point |
| 2024-09-30 00:36:37 +0200 | <andrewboltachev> | but PostgreSQL is good at nosql (if you want it). Or is it? |
| 2024-09-30 00:36:19 +0200 | alp | (~alp@user/alp) (Remote host closed the connection) |
| 2024-09-30 00:36:04 +0200 | <geekosaur> | unsurprisingly, nosql dbs are terrible at sqlish things |
| 2024-09-30 00:36:03 +0200 | <andrewboltachev> | i.e. two column tables — uuid and data (jsonb) |
| 2024-09-30 00:35:42 +0200 | <andrewboltachev> | yes that team used JSONB |
| 2024-09-30 00:35:29 +0200 | <geekosaur> | sounds like second generation nosql to me |
| 2024-09-30 00:34:44 +0200 | <__monty__> | I'm skeptical working around the lack of foreign keys would usually be more performant than letting the DB engine do its thing. |
| 2024-09-30 00:34:43 +0200 | <geekosaur> | this kind of stuff means postgresql has higher overhead, but that overhead is fairly fixed so it becomes a smaller part of the cost as tables/indexes get larger |
| 2024-09-30 00:34:41 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-09-30 00:34:04 +0200 | <geekosaur> | and keeps no key statistics so it can't use those to similarly optimize how to do joins |
| 2024-09-30 00:33:26 +0200 | <geekosaur> | (for example it doesn't know how to use relative table sizes to determine when it's better to do the join from the other direction) |
| 2024-09-30 00:32:50 +0200 | <geekosaur> | basically it has no clue about query optimization, so where postgresql and even mariadb will optimize joins to at leats some extent, sqlite will keep brute-forcing them |
| 2024-09-30 00:31:50 +0200 | <andrewboltachev> | (didn't learn how to read output of EXPLAIN yet) |
| 2024-09-30 00:31:47 +0200 | <geekosaur> | this is the price of being small and simple |
| 2024-09-30 00:31:37 +0200 | <geekosaur> | sqlite's just bad at jpining; it works best with single flat tables |
| 2024-09-30 00:31:23 +0200 | Eoco | (~ian@128.101.131.218) Eoco |
| 2024-09-30 00:31:18 +0200 | <monochrom> | Why is sqlite bad with foreign keys? If I create an index for the foreign key column, will it be much better? |
| 2024-09-30 00:31:03 +0200 | <andrewboltachev> | geekosaur: I believe there's a lot of science happening under the hood of Postgres :-) |
| 2024-09-30 00:30:59 +0200 | alp | (~alp@user/alp) alp |
| 2024-09-30 00:30:59 +0200 | alp | (~alp@2001:861:e3d6:8f80:9956:3934:6a0b:7b98) (Changing host) |
| 2024-09-30 00:30:50 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb46757e16ffb08be72b.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-09-30 00:30:47 +0200 | alp | (~alp@2001:861:e3d6:8f80:9956:3934:6a0b:7b98) |