Fwd: Re: [PERFORM] Presentation - Mailing list pgsql-advocacy

----------  Forwarded Message  ----------

Subject: Re: [PERFORM] Presentation
Date: Wed, 8 Oct 2003 13:05:28 -0400 (EDT)
From: Jeff <threshar@torgo.978.org>
To: Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Cc: "pgsql-advocacy@postgresql.org" <pgsql-performance@postgresql.org>

On Wed, 8 Oct 2003, Shridhar Daithankar wrote:
> * Same slide. IIRC postgresql always compresses bytea/varchar. Not too much
> sure about which but there is something that is compressed by default..:-)
>
> * Tablespaces has a patch floating somewhere. IIRC Gavin Sherry is the one
> who is most ahead of it. For all goodness, they will feature in 7.5 and
> design is

For the sake of things, I didn't include any features a patch provides. I
did include things that may appear in contrib/.

> * Mysql transaction breaks down if tables from different table types are
> involved. * Mysql transactions do not feature constant time commit/rollback
> like postgresql. The time to rollback depends upon size of transaction
> * Mysql does not split large files in segments the way postgresql do. Try
> storing 60GB of data in single mysql table.

I didn't add these ones. The user can figure this one out.
Perhaps when we/me expands this into multiple documents we can expand on
this.

> * Slide on caching. Postgresql can use 7000MB of caching. Important part is
> it does not lock that memory in it's own process space. OS can move around
> buffer cache but not memory space of an application.

I'm guilty of this myself - when I first started pg I was looking for a
way to make it use a zillion megs of memory like we have informix do -
Perhaps I'll reword that segment.. the point was to show PG relies on the
OS to do a lot of caching and that it doesn't do it itself.

> * Using trigger for maintening a row count would generate as much dead rows
> as you wanted to avoid in first place..:-)

We all know this.. but it is a way to get a fast select count(*) from
table

> All of them are really minor. It's a very well done presentation but 45
> slides could be bit too much at a time. I suggest splitting the
> presentation in 3. Intro and comparison, features, administration,
> programming and tuning. Wow.. they are 5..:-)

Yeah. What I'd really love to do is de-powerpointify it and make it a nice
set of "real" web pages.

> Can you rip out informix migration? It could be a good guide by itself.

I agree. It would be good to rip out. I think we have the oracle guide
somewhere..


I've put this updated on up on hte postgres.jefftrout.com site
along with openoffice version.


--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

-------------------------------------------------------

--
Josh Berkus
Aglio Database Solutions
San Francisco