[Xastir-Dev] Short list, stable release, then Xastir-2 development?

[Curt Mills, WE7U]

On Fri, 14 Mar 2003, Jeff Brenton KA9VNV wrote:

> Hopefully, another "feature" of Postgres will not be a problem with
> what's being discussed here. It seems on some databases, with lots of
> large inserts and deletes, Postgres can start eating disk space for
> seemingly no reason (there are reasons, but they aren't obvious).

The large inserts we'll be doing will be Shapefile maps (and perhaps
other types).  We'll typically not be doing much deleting of that
data.

Packet data will be rather small inserts/deletes, but lots of them.
Perhaps the PostgreSQL problem has to do with fragmentation of the
available space, which seems likely.  If that's the main problem,
and we set up our tables/fields to be of a fixed size, we can reduce
that problem right from the get-go.


> This is a critical item for another project I'm involved in, which
> uses either Postgres or MySQL as the back end for mail servers.
> Postgres has several advantages that some people want (the triggers
> and stored procedures), but it comes with the cost of slower inserts
> and queries, AND the necessity of running VACUUM several times per day
> to keep the database sizes in check.

One of the reasons why PostgreSQL is considerably slower is that by
default they take a more conservative approach to committing new
data, while MySQL kind'a runs wild in this regard.  PostgreSQL can
be setup up to do commits more like MySQL does, in which case it's
much faster at doing inserts.  I kind'a like the conservative
approach myself though.

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"