PostgreSQL

I'm doing an extension that creates a pool of named background workers. Happy to hear any feedback on this.

CREATE EXTENSION pg_worker_pool;
CALL worker_pool.submit('foo', 'create index myindex_1 on my_big_table (id)');
CALL worker_pool.submit('foo', 'create index myindex_1 on my_big_table (name)');
CALL worker_pool.submit('bar', 'create index otherindex_2 on other_big_table (author)');
CALL worker_pool.submit('bar', 'create index otherindex_2 on other_big_table (title)');

This will start two background workers, foo and bar. foo will create an indices on table my_big_table and bar on table other_big_table. foo and bar will run independently of each other, but all indices submitted to the same worker will be created in order.

What are your experiences with @postgresql jsonb columns as document store?

Is it easy to use from a Spring App? How fast is it? What are its limitations?

#postgresql #json #databases

Via https://fosstodon.org/@hunleyd/113205392466307810

Via https://fosstodon.org/@hunleyd/113080821469886930

Via https://mastodon.social/@stevenan/112899205276153700

Via https://mastodon.social/@[email protected]/112220150255942506

Prolog language for PostgreSQL

This is a PostgreSQL extension that allows writing stored procedures in Prolog.

This embeds Scryer Prolog into a PostgreSQL extension.

Proof of concept! Not ready for any actual use.

PostgreSQL maintainer Simon Riggs has died in a small airplane crash, on Tuesday.

For those who didn't know Simon, he's responsible for PostgreSQL Binary Replication and many big data features. He and I worked together at Greenplum 2006-2008. Postgres would not be the world-leading DB it is today if it weren't for him.

https://www.bbc.com/news/articles/cjex992z0wlo

Lemmy currently uses distinct tables like post_like: (post_id, person_id, score) and post_saved. Unfortunately this causes performance issues when we have to join many of these tables to create views.

One suggestion in this PR, is to combine these into a single post_action table, with a lot of optional columns depending on the action. This solution scares me a little, because I'm afraid we might lose data integrity, and many of our constraints with so many optional columns.

Is there a better way of doing this in SQL?

Is it possible to upgrade PostreSQL from 14 to 16 directly when using containers?
@postgresql