Showing posts with label tutorial. Show all posts
Showing posts with label tutorial. Show all posts
Tuesday, April 3, 2018
New Annotated Config Files for PostgreSQL 10
Teal Deer: The Annotated.conf has been updated for PostgreSQL 10, and it's a Github repo now.
13 years ago, for PostgreSQL 8.0, I released the first Annotated.conf because we had (at that time) over 140 configuration settings and most people had no idea how to set them. Today Postgres has nearly twice as many (269), and the problem is twice as bad. More about that later.
The repository is intended to be a quick reference for how to figure out how to set a lot of these parameters. It includes my tutorial slides in both Libreoffice and PDF format, and a giant table of settings and recommendations in either CSV format or as a PostgreSQL 10 database dump. Accompanying each setting are my notes on why you'd change the setting and, if so, to what.
Probably more usefully, I've included two sample .conf files. postgresql.10.simple.conf contains the 20 most commonly changed settings with detailed advice on how to set them. extra.10.conf has the next 20 most-likely-to-be-changed settings, with somewhat more limited advice. The idea is for you follow the instructions, and then drop one or both of these files into your include_dir configuration directory and have a more sensible configuration without messing with the preposterously long default configuration file that ships with most PostgreSQL packages. Those 20 to 40 settings should cover 90% of the needs of 90% of users.
If you feel that my advice is inaccurate, incomplete, or out-of-date, then Github has both Issues and Pull Requests available for you to suggest replacements.
Now, I can't help but feel that the configuration situation with PostgreSQL is getting worse. While the database has improved with some better sensible defaults, and some good auto-configuration code (for example, for transaction log size), overall both the number of settings and the number of settings most users have to care about keeps going up.
The worst part of this is settings added with absolutely no information on how to determine a reasonable level for the setting. For example, these four data flushing settings were added in version 10:
#backend_flush_after
#bgwriter_flush_after
#checkpoint_flush_after
#wal_writer_flush_after
... but there is no concrete advice on how to set these. Yes, there are docs, but even as someone who has a solid grounding in database, memory, and filesystem performance, I'd hesitate to recommend any specific level for these for a specific problem. I'd like to be optimistic and assume that an explanation is coming in Postgres 11 or so, but after four years there's still nothing on how to set vacuum_multixact_freeze_min_age.
In the meantime, hopefully annotated.conf gives you a good start on tinkering with your own PostgreSQL settings.
Thursday, December 31, 2015
Speaker Practice Survey
VM Brasseur and I are doing a speaker training tutorial at SCALE14, entitled "10 Step Program for Great Tech Talks." As experienced speakers who go to a lot of conferences, we have way too much material for a three hour tutorial, and need to know what to cut. So she had the idea of doing a survey of conference attendees, which we conducted over a couple weeks. The survey was meant to find out what frequent conference attendees liked about good talks, and didn't like about not-so-good talks.
You can check out the original survey here, although we're no longer paying attention to responses.
First let's find out who our surveyees are. 108 people responded. Given that VM and I broadcasted the survey over Twitter, as did Josh Simmons and Gareth Greenaway, I expect that our sample will be fairly skewed; let's see. First we asked people whether they just attend talks, or whether they both give and attend them.
As you can see, our sample skews heavily towards presenters, with a minority of pure audience members. A few wiseacres said they only give talks, and don't attend them, which wasn't supported by their other answers. We also asked how many conferences and talks folks went to in the last year:
So, most of our respondees are frequent conference and/or talk attendees. This colors the rest of the survey; what we're looking at is what a group of experienced people who go to a lot of talks, and present more than a few, think of other speakers' performance. I suspect that if we did a survey of folks at their very first tech conference, we would see somewhat different data.
We asked "Thinking of the presentations you attended with topics and/or speakers you've most enjoyed, what speaker behaviors below do you feel substantially added to the experience?". The idea of this question was to find out what skills or actions by the speaker were the most important for making a talk valuable. Each item was rated on a 1-5 scale.
The above graph requires some explanation. The length of the bars is the average score. The bars are ranked from the highest to lowest rated practice. The color of the bars indicates the median score, for cases where the average is deceptively skewed: Red 5, Blue 4, Green 3, and Black 2.
We can see a few things from this. First, no practice was considered completely unimportant; nothing averaged below 2.1. Good narrative structure was clearly the best liked practice, with deep subject knowledge and being an energetic speaker as our second and third ranked items.
If you look at the overall rankings, you can see that "content" items are the best loved, whereas talk "extras" and technical improvements are the least important. Slide visual design, which many speakers spend a lot of time sweating over, just averages 3.0, and the three items involving technical interaction with the audience (demos, participation, and exercises), come in last. I do wonder whether those three are last because they are so seldom done well, even by experienced speakers, or because they really are unimportant. Let me know what you think in the comments.
To balance this out, we asked surveyees, "Thinking of the presentations you attended with topics and/or speakers you liked, what speaker behaviors below do you feel substantially detracted from, or even ruined, an otherwise good presentation?" The idea was not to find out why sucky presentations sucked, but what things prevented an acceptable talk from being good. Here's the ratings, which are graphed the same way as the "good" ratings:
The top two speaking problems were not being able to hear or understand the speaker, and the presenter being bored and/or distracted. The first shows how important diction, projection, and AV systems are to having a good talk -- especially if you're speaking in a language which isn't your primary one. The second is consistent with the good speaker ratings: people love energetic speakers, and if speakers are listless, so is the audience. So make sure to shoot that triple espresso before you go on stage.
There were a few surprises in here for me. Unreadable code on slides, one of my presonal pet peeves, was a middle-ranker. Running over or under time, which I expected to be a major talk-ruiner, was not considered to be. Offensive content, on the other hand, is a much more widespread problem than I would have assumed.
And "ums" and body language problems, however, ranked at the bottom. From my own observation, I know that these are common issues, but apparently they don't bother people that much. Or do they?
Finally, we asked, "If you could magically eliminate just one bad speaker behavior from all presenters everywhere, which one would it be?" The idea was to find out what one thing was really driving audiences bananas, it was so bad. Here's the responses:
So, first, there are a few things which are inconsistent with the ratings. Unpracticed presentations were the #1 issue, and some other items which looked unimportant by rating, like saying "um" a lot, show up as a top pet peeve. So apparently people hate "um" and interruptions a lot, but they don't see them ruining that many otherwise good talks. The other top issues match the ratings we already saw.
About a seventh of the responses were ones which received only one or two votes, including an assortment of write-in responses. Here's a few of the more interesting ones:
So this survey will give us enough information to know what things we can cut back on in order to make our timeslot ... and even a few things to spend more time on! If you want to learn more about how to be a great speaker, join us at SCALE14 on the morning of Thursday, January 21.
If you just like the graphs, both the graphs and the IPython notebook used to produce them are on our Github repo.
You can check out the original survey here, although we're no longer paying attention to responses.
Demographics
First let's find out who our surveyees are. 108 people responded. Given that VM and I broadcasted the survey over Twitter, as did Josh Simmons and Gareth Greenaway, I expect that our sample will be fairly skewed; let's see. First we asked people whether they just attend talks, or whether they both give and attend them.
As you can see, our sample skews heavily towards presenters, with a minority of pure audience members. A few wiseacres said they only give talks, and don't attend them, which wasn't supported by their other answers. We also asked how many conferences and talks folks went to in the last year:
So, most of our respondees are frequent conference and/or talk attendees. This colors the rest of the survey; what we're looking at is what a group of experienced people who go to a lot of talks, and present more than a few, think of other speakers' performance. I suspect that if we did a survey of folks at their very first tech conference, we would see somewhat different data.
The Good
We asked "Thinking of the presentations you attended with topics and/or speakers you've most enjoyed, what speaker behaviors below do you feel substantially added to the experience?". The idea of this question was to find out what skills or actions by the speaker were the most important for making a talk valuable. Each item was rated on a 1-5 scale.
The above graph requires some explanation. The length of the bars is the average score. The bars are ranked from the highest to lowest rated practice. The color of the bars indicates the median score, for cases where the average is deceptively skewed: Red 5, Blue 4, Green 3, and Black 2.
We can see a few things from this. First, no practice was considered completely unimportant; nothing averaged below 2.1. Good narrative structure was clearly the best liked practice, with deep subject knowledge and being an energetic speaker as our second and third ranked items.
If you look at the overall rankings, you can see that "content" items are the best loved, whereas talk "extras" and technical improvements are the least important. Slide visual design, which many speakers spend a lot of time sweating over, just averages 3.0, and the three items involving technical interaction with the audience (demos, participation, and exercises), come in last. I do wonder whether those three are last because they are so seldom done well, even by experienced speakers, or because they really are unimportant. Let me know what you think in the comments.
The Bad
To balance this out, we asked surveyees, "Thinking of the presentations you attended with topics and/or speakers you liked, what speaker behaviors below do you feel substantially detracted from, or even ruined, an otherwise good presentation?" The idea was not to find out why sucky presentations sucked, but what things prevented an acceptable talk from being good. Here's the ratings, which are graphed the same way as the "good" ratings:
The top two speaking problems were not being able to hear or understand the speaker, and the presenter being bored and/or distracted. The first shows how important diction, projection, and AV systems are to having a good talk -- especially if you're speaking in a language which isn't your primary one. The second is consistent with the good speaker ratings: people love energetic speakers, and if speakers are listless, so is the audience. So make sure to shoot that triple espresso before you go on stage.
There were a few surprises in here for me. Unreadable code on slides, one of my presonal pet peeves, was a middle-ranker. Running over or under time, which I expected to be a major talk-ruiner, was not considered to be. Offensive content, on the other hand, is a much more widespread problem than I would have assumed.
And "ums" and body language problems, however, ranked at the bottom. From my own observation, I know that these are common issues, but apparently they don't bother people that much. Or do they?
The Ugly
Finally, we asked, "If you could magically eliminate just one bad speaker behavior from all presenters everywhere, which one would it be?" The idea was to find out what one thing was really driving audiences bananas, it was so bad. Here's the responses:
So, first, there are a few things which are inconsistent with the ratings. Unpracticed presentations were the #1 issue, and some other items which looked unimportant by rating, like saying "um" a lot, show up as a top pet peeve. So apparently people hate "um" and interruptions a lot, but they don't see them ruining that many otherwise good talks. The other top issues match the ratings we already saw.
About a seventh of the responses were ones which received only one or two votes, including an assortment of write-in responses. Here's a few of the more interesting ones:
- "Reading slide content to audience" (two votes, including a page-long tirade)
- "Giving the talk using slides that are really optimized to be downloaded by someone who isn't able to attend the talk. Presentation slides and downloadable slides are different beasts."
- "Long personal company or employment history introductions"
On to the Tutorial
So this survey will give us enough information to know what things we can cut back on in order to make our timeslot ... and even a few things to spend more time on! If you want to learn more about how to be a great speaker, join us at SCALE14 on the morning of Thursday, January 21.
If you just like the graphs, both the graphs and the IPython notebook used to produce them are on our Github repo.
Tuesday, November 10, 2015
Ready to be an Accidental DBA at pgConfSV?
My AccidentalDBA tutorial materials have been updated for pgConfSV next week. If you are planning to take this tutorial, please read and follow the setup instructions before you get to the conference.
I created this tutorial in 2009 because of the number of people these days who find themselves in charge of a PostgreSQL server ... or many servers ... without any DBA background, training, or desire to be ops. The tutorial is intended to teach you the minimum you need to keep your PostgreSQL server from falling over so you can get back to whatever your main job is.
You can take it self-paced if you can't make it to pgConfSV. The tutorial includes all materials and notes. In this version, I've added the option of a Docker container (preferred), pg_stat_statements, and a restore-to-point-in-time exercise.
If you are going to attend this tutorial, note that it requires advance setup which will be harder to perform once you get to your hotel, and near-impossible if you wait until 10 minutes before it starts. So read up and install now.
And ... I believe there's still a few registrations left for the tutorial day, so consider signing up. You have nothing to lose but your fear of database admin!
I created this tutorial in 2009 because of the number of people these days who find themselves in charge of a PostgreSQL server ... or many servers ... without any DBA background, training, or desire to be ops. The tutorial is intended to teach you the minimum you need to keep your PostgreSQL server from falling over so you can get back to whatever your main job is.
You can take it self-paced if you can't make it to pgConfSV. The tutorial includes all materials and notes. In this version, I've added the option of a Docker container (preferred), pg_stat_statements, and a restore-to-point-in-time exercise.
If you are going to attend this tutorial, note that it requires advance setup which will be harder to perform once you get to your hotel, and near-impossible if you wait until 10 minutes before it starts. So read up and install now.
And ... I believe there's still a few registrations left for the tutorial day, so consider signing up. You have nothing to lose but your fear of database admin!
Tuesday, July 16, 2013
Accidental DBA and More at OSCON next week
O'Reilly OSCON is next week, and I'll be attending for the first time since 2009. I'll be teaching the Accidental DBA tutorial, for which I've just uploaded the preparation materials. There's also lots of other PostgreSQL and community-building content, much of which I'm involved in.
As an experiment, I'm trying to do hands-on for this tutorial by using Vagrant, which will provide each attendee with a nice VM they can use to try out various PostgreSQL administrative commands. Of course, this means that attendees need to download, install, and run setup on Vagrant before the tutorial, and preferably while they are still at home with good internet access. I've a feeling that 20 people will want to try to install it the morning of the tutorial, which won't work. I'm also conflicting with "predictive R analytics", dammit.
If you're attending the tutorial, preparation materials are here.
As usual, there will be a significant amount of PostgreSQL content aside from my own tutorial, which includes:
So, if you're going to be at OSCON, I'll no doubt see you there!
As an experiment, I'm trying to do hands-on for this tutorial by using Vagrant, which will provide each attendee with a nice VM they can use to try out various PostgreSQL administrative commands. Of course, this means that attendees need to download, install, and run setup on Vagrant before the tutorial, and preferably while they are still at home with good internet access. I've a feeling that 20 people will want to try to install it the morning of the tutorial, which won't work. I'm also conflicting with "predictive R analytics", dammit.
If you're attending the tutorial, preparation materials are here.
As usual, there will be a significant amount of PostgreSQL content aside from my own tutorial, which includes:
- Christophe Pettus doing PostgreSQL as a NoSQL Database
- Dimitri Fontaine doing Large Scale MySQL Migration to PostgreSQL
- A PostgreSQL booth in the Trade Show
- PDXPUG event, including me and Dimitri speaking, and beer, on Wednesday night.
- There's also been some talk about a Big Data event Tuesday night.
So, if you're going to be at OSCON, I'll no doubt see you there!
Friday, March 22, 2013
Speaker training at Linux Collab, LinuxCon
Are you a first-time speaker? Have you noticed most of the audience checking their email during your talks? Are you speaking to a mostly-empty room, and not getting invited back to conferences? Do you walk out of the room thinking "that could have gone better"? Are you a brilliant technology inventor, yet at a loss when standing in front of an audience? Are you just regularly speaking at conferences, but have never attended a speaker training before?
If the answer to any of the above is "yes", then you need to attend my speaker training at the Linux Collab Summit or at LinuxCon this year. I'll be reprising "Give A Great Tech Talk", the speaker training Ian Dees and I developed for Open Source Bridge -- with some improvements, additions and advances, of course! This session is strongly recommended for all new speakers by the Linux Foundation, and even experienced speakers can pick up a few useful tips.
Since we'll have a longer timeslot for this than we did at Open Source Bridge, I'll be doing more audience exercises. If you're attending, please bring your notes and slides for some of your own presentations, and we'll work on them.
See you there.
If the answer to any of the above is "yes", then you need to attend my speaker training at the Linux Collab Summit or at LinuxCon this year. I'll be reprising "Give A Great Tech Talk", the speaker training Ian Dees and I developed for Open Source Bridge -- with some improvements, additions and advances, of course! This session is strongly recommended for all new speakers by the Linux Foundation, and even experienced speakers can pick up a few useful tips.
Since we'll have a longer timeslot for this than we did at Open Source Bridge, I'll be doing more audience exercises. If you're attending, please bring your notes and slides for some of your own presentations, and we'll work on them.
See you there.
Subscribe to:
Comments (Atom)
