Newest at the top
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) |
2024-09-30 00:30:31 +0200 | <hololeap> | lol |
2024-09-30 00:30:20 +0200 | <hololeap> | it's cool I just threw it out because at first glance it seemed vaguely relevant to the backlog I bothered to read |
2024-09-30 00:29:14 +0200 | <andrewboltachev> | hololeap: thanks. sorry |
2024-09-30 00:29:13 +0200 | <geekosaur> | postgres has this thing where it's slower than simpler dbs for small tables, but scales far better than other databases as they get larger and more joins are involved |
2024-09-30 00:28:26 +0200 | <andrewboltachev> | yes I worked with ppl who denied fks in Postgres in "pursuit" for performance |
2024-09-30 00:28:25 +0200 | <hololeap> | the article mentions three different approaches, including nullable columns |
2024-09-30 00:27:29 +0200 | <geekosaur> | mariadb is poor |
2024-09-30 00:27:06 +0200 | <geekosaur> | depends on the db, really. sqlite will be bad, postgresql should be reasonable |
2024-09-30 00:26:40 +0200 | <andrewboltachev> | so one approach is to have e.g. "type" column and then several nullable columns, where each subset is for particular type etc etc |
2024-09-30 00:26:08 +0200 | Eoco | (~ian@128.101.131.218) (Client Quit) |
2024-09-30 00:26:03 +0200 | <andrewboltachev> | hololeap: also, some ppl say that having extra constraints in SQL will make db perform slower. (some even say that Foreign keys make it slow) |
2024-09-30 00:25:55 +0200 | Eoco | (~ian@128.101.131.218) Eoco |
2024-09-30 00:25:16 +0200 | Eoco | (~ian@128.101.131.218) (Client Quit) |
2024-09-30 00:25:12 +0200 | <hololeap> | ok |
2024-09-30 00:25:06 +0200 | Eoco | (~ian@128.101.131.218) Eoco |
2024-09-30 00:24:35 +0200 | Eoco | (~ian@128.101.131.218) (Quit: WeeChat 4.1.1) |
2024-09-30 00:24:30 +0200 | <andrewboltachev> | hololeap: well, this is for SQL, but I rather mention "Categorical Databases" :-) |
2024-09-30 00:24:13 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
2024-09-30 00:23:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-30 00:22:00 +0200 | <hololeap> | andrewboltachev: https://www.parsonsmatt.org/2019/03/19/sum_types_in_sql.html ? |
2024-09-30 00:18:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
2024-09-30 00:17:13 +0200 | <andrewboltachev> | if I generalize the idea (which I want) and the "generalized table" has also coproducts, e.g. either "pickup" or "delivery" (for a web store like Amazon perhaps) then how do they map coproduct onto Set |
2024-09-30 00:16:22 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2024-09-30 00:15:47 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) machinedgod |
2024-09-30 00:14:54 +0200 | <andrewboltachev> | but I believe it only works for them 'cause single "database table" is like a product of fields: (e.g. first_name, last_name, email, password etc) |
2024-09-30 00:13:51 +0200 | <andrewboltachev> | in, for example "Categorical Databases" by David Spivak et al they talk about a "Database instance" functor C -> Set |
2024-09-30 00:13:06 +0200 | <andrewboltachev> | coproducts (in ADTs) have been a problem (or main point of interest?) for me in this (bigger) idea that I research |
2024-09-30 00:11:20 +0200 | Eoco | (~ian@128.101.131.218) Eoco |