Please talk about database views, both regular and materialized. When they are best used, strengths and weaknesses. Compare composing a combined query out of CTE's and sub-queries.
Hot standby. How to promote a slave to master. Continuous archiving. Effective logging and analysing with eg. PgBadger. Performance tuning and benchmarking.
Best practices around those tasks would really be helpful.
A screencast on using PG to handle stuff that is often stored in noSQL databases would be interesting. I'd be interested in both using PG's new noSQL capabilities but more importantly also in walking through creating a Schema for the data (and the tradeoffs).
I'd suggest mining some Tweets with metadata from the streaming API (JSON) and using that as a running example.
This is a great idea. Thanks. PostgreSQL is a very complicated and feature rich system but has a steep learning curve once you deviate from the basic CRUD. Even though the documentation is decent its not very beginner friendly - hopefully the screencasts will grow in number and topics to help make Postgre more mainstream.
It is quite awesome. It'd be even more awesome if it had support for kerberos (and delegation) built in so I didn't have to write an external JWT provider, if I could rely on PostgreSQL's built-in kerberos support for authentication it would be amazing.
Pretty easy to get just from reading the first couple paragraphs of the documentation. Postgres has three string types, CHARACTER, CHARACTER VARYING, and TEXT.
CHARACTER VARYING is the basic type of string, and can be given with a maximum character length. If no length is given, the max value is assumed.
CHARACTER is a padded string - all strings are padded to the specified length with spaces. If no length is given, the length 1 is assumed.
TEXT is an alias for a CHARACTER VARYING without a length parameter (max length).
Actually all string types are handled the same internally, and there's no performance reason to use CHARACTER instead of CHARACTER VARYING. In fact it may hurt performance since the padding increases the data size. Using length constraints also carries a slight performance hit during writes as the constraint gets checked.
Basically, it optimizes for lots of insert operations by using a composite primary key, one of which is a SERIAL assigned by the server, and the other is a value arbitrarily assigned by the client. This allows a client to assign and use many new unique keys without asking the server for a new value for every individual row.
We'd love feedback on the screencasts and suggestions on topics that you'd like to see covered!