Skip site navigation (1) Skip section navigation (2)

Re: Guidlines for a PostgreSQL Speech/Tutorial

From: "Scott Marlowe" <smarlowe(at)qwest(dot)net>
To: aspire420(at)hotpop(dot)com
Cc: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Guidlines for a PostgreSQL Speech/Tutorial
Date: 2004-08-17 21:51:28
Message-ID: 1092779488.17763.16.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacy
On Sat, 2004-08-14 at 13:10, V i s h a l Kashyap @ [Sai Hertz And
Control Systems] wrote:
> Hopeless and I thought I would get help.
> Stupid me.
> > Dear all ,
> >
> > I am an Electronics and Telecommunication engineer some how managed to 
> > come into
> > development side.
> > In PostgreSQL I have done a project which is related to Rural Banking.
> > Here In India we have a annual Linux meet organized by one and only 
> > Asia's Linux magazine
> > "Linux For You".
> > I am planning to represent PostgreSQL people in this meet.
> > But am stuck with following questions :
> > 1. What stuff should I study the most.
> > 2. What topics must I cover in the meet that will give PostgreSQL a  
> > big boost
> > 3. Should I give a tutorial or just a speech about the features of  
> > PostgreSQL.
> > 4. Scary  topic for me is Object oriented part of PostgreSQL.
> > 5. Their are many more questions but would ask them all once this 
> > thread grows.
> >
> > moreover I would be happy to receive guidelines and text of any 
> > previous PostgreSQL  presentation from you kind people.
> >
> > The meet is in January 2005
> >
> > With Warm Regards,
> > Vishal Kashyap
> >

I'd be glad to help.  I was on vacation over the weekend and didn't see
your message.  I hope it's ok with you if I take a vacation every now
and then I know how much you pay me to sit here and answer your posts
for you, oh wait a minute.  Anyway...  I've still got 600 emails from
the lists I'm subscribed to that I need to slog through, so this won't
be the long version.

Here are some of the facts I generally cover when giving a postgresql

MVCC and the fact that postgresql indexes always point into the data
store (i.e. you never get the value from just the index) means
postgresql switches to seq scans quicker than other databases.

PostgreSQL is quite programmable, with a dozen or so procedural

PostgreSQL is designed to have the power plug pulled while in the middle
of transactions, and it should come back up coherent and ready to run in

PostgreSQL's DDL as well as DML is fully transactable, except, of
course, create / drop database.

PostgreSQL is designed to handle massive parallel loads well, and can
take advantage of large disk sets on RAID 1+0 / RAID 5 et. al. but tends
to not be CPU bound much.

aggregates tend to be slow for certain operations, and their work
arounds (i.e. select id from table order by id limit 1 instead of
max(id) ).

I usually give a full blown demonstration, using the psql command prompt
to show the simple yet powerful interface and what a user can do with

Don't worry about administration so much, that's for later.

I don't for the most part use any of the object relation stuff (i.e.
inheritance) when using postgresql, as I'm a bit more of a relational
purist.  I also don't use arrayed types, since 99.9% of the time another
table works better.

There are some things online from Bruce's and Tom's and a few other
folks presentations in the past at places like OSCON.

However, PostgreSQL 8.0 just entered beta, so those guys are VERY busy. 
Take a look at the OSCON section of the O'Reilley site to see what's
hanging there, and I'll see what I can dig up.  But give the guys making
this database a break for now, they're working hard on making it better
and getting through beta, which is a breathtakingly fast moving process,
leaving them little time to chat on the advocacy lists at the moment.

In response to

pgsql-advocacy by date

Next:From: Jan WieckDate: 2004-08-18 15:57:35
Subject: Re: Time to work on Press Release 8.0
Previous:From: Simon RiggsDate: 2004-08-17 20:46:26
Subject: Re: News of the LJ award has hit Slashdot

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group