Re: Getting to beta1

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 gather information
about running queries at any time. Another such view is pg_locks,
which reports about current lock requests and 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 for a 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 different terminals, or using
pgadmin. Now <instruction for 2 concurrent UPDATE on the same
row>. Use the previous query to see 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