Tom Lane <tgl@sss.pgh.pa.us> writes:
> This sounds like a pretty horrid idea. The tutorial is meant to be read
> first, so it cannot depend on having already read any of the main
> documentation. If we try to fill it with "hints and tricks" then either
> it will be completely unintelligible to newbies, or there will be a
> staggering amount of material duplicated from the main docs to support
> the hints. The latter approach would be no fun to write and even less
> fun to maintain in the future.
I'm not sure how much your comment applies to what I picture, so here's
what I had in mind:
There's a system view called pg_stat_activity which is maintained up-to-date by PostgreSQL, and you can query it to
gatherinformation about running queries at any time. Another such view is pg_locks, which reports about current lock
requestsand whether they're granted or not.
You can use both those system views to get important information on your running system, and to show currently waiting
fora lock query texts, here's how you join those views:
<insert recipe from the link> http://wiki.postgresql.org/wiki/Lock_Monitoring
To produce a locking situation, let's open two concurrent connections to the database, either with psql in two
differentterminals, or using pgadmin. Now <instruction for 2 concurrent UPDATE on the same row>. Use the previous query
tosee the locked query, commit the first session to unlock it.
As the concepts of SELECT, view and JOINs are already addressed in the
tutorial, I'd think it could be ok. Now, maybe the tutorial isn't the
right place to be confronted to MVCC, locks, and system monitoring, but
some kind of soft introduction would be good here, methinks.
> There might well be a use for a separate hints-and-tricks document.
> I don't agree with stuffing it into the existing tutorial though.
Yeah, maybe expanding current chapter 27. Monitoring Database Activity
would be a better idea?
http://developer.postgresql.org/pgdocs/postgres/monitoring.html
In fact, a merge of chapters 27 and 28 Monitoring Disk Usage into a
larger one about Monitoring PostgreSQL could be a better fit?
Regards,
--
dim
