From: | Guyren Howe <guyren(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Is there a good discussion of optimizations? |
Date: | 2020-12-24 01:55:57 |
Message-ID: | 34fa7876-2346-4cb4-a094-d20963518286@Spark |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I’d like to put together a good video and writeup about what the… philosophy behind relational databases is.
Most folks, in my experience, who use relational databases don’t really understand the basic theory or even more important the why — the philosophy — of what a relational database is and how to get the most out of them. I see a lot of folks trying to use SQL in an imperative manner — make this temp table, then update it some, then make this other temp table, etc… I see this particularly among analysts who for some reason often prefer SQL Server. I think this is down to afaict SQL Server having an abominable query optimizer. Comments on SQL Server’s query optimizer or this culture of temp tables are welcome.
Anyway, I’d like to put together something that explains this. I would go into Codd’s original insight and how simple yet powerful it is. I’d like to discuss how if you stick to SQL, rather than forcing it into this imperative straight-jacket, the database can work out all the details so you don’t have to do the bad things. It would be useful if there is some reasonably accessible discussion to go through the sort of query optimizations that Postgres can do for you, to convince folks that they can stick to describing what they want, not how to get it.
I’d be interested in any comments anyone has about useful things to discuss here, and in particular I’m interested in an accessible discussion of the sorts of query optimizations Postgres can do for us.
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2020-12-24 02:58:36 | Re: [PATCH] Logical decoding of TRUNCATE |
Previous Message | Tom Lane | 2020-12-24 01:43:08 | Re: Range search on primary key does not use index scan |