Build A GPT In SQL | Scaling Postgres 299

Рет қаралды 653

Күн бұрын

To get the show notes as well as get notified of new episodes, visit:
www.scalingpostgres.com/episo...
In this episode of Scaling Postgres, we discuss how you can build a GPT in 500 lines of SQL code, how to optimize extension loading, the best way to set passwords and being able to change generated columns.
Want to learn more about Postgres performance?
Join my FREE mini-course called the PostgreSQL Performance Starter Kit here: www.scalingpostgres.com/cours...
Timestamps:
00:00 - Intro
00:29 - Happy New Year: GPT in 500 lines of SQL
02:31 - Optimizing PostgreSQL functions with preloaded libraries
03:57 - Postgres password encryption without leaking credentials
05:51 - Waiting for PostgreSQL 17 - ALTER TABLE command to change generation expression
06:52 - Postgres Postmaster File Explained
07:54 - pgBadger
08:41 - Understanding PostgreSQL Aggregation and Hyperfunctions’ Design
10:08 - Introducing pg_query for Postgres 16 - Parsing SQL/JSON, Windows support, PL/pgSQL parse mode & more
10:51 - How to speed up COUNT(DISTINCT)
11:25 - Introducing a new community wiki page "Operations cheat sheet"
11:35 - Operations cheat sheet
11:49 - Outro
#postgres #postgresql

Пікірлер: 5

@vinny142 6 ай бұрын

Explain Extended's new-year's posts are a treat! I've used them many times to show people that databases are more than just string-storage.

@professortrog7742 6 ай бұрын

Preloading large libraries like postgis or R comes at a hefty cost: the several megabytes is loaded into *each* connection’s space, so with 1000 connections there will be 5 to 8 GB of library code just sitting around.

@ScalingPostgres 6 ай бұрын

This brings up a good point. That probably means that if you really wanted to optimize things, you should dedicate statements that use these libraries to their own connections. Even if you are not preloading, if you use one of these libraries with 1000+ connections, all the connections will eventually load the libraries.