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

[Gerry Creager N5JXS]

Or, more precisely, separate tables. We don't need several instances of 
the database running.  That _would_ be a resource hog.

PostGIS extensions to PostGres are where we're heading.  That'll deal 
with the spatial element almost as well (and some I work with say better 
than) as Oracle Spatial9i.

Gerry

Tom Young wrote:
> It would most likely be advisable to use separate databases for maps
> (low volatility) versus APRS packets (high volatility).  This would also
> allow for separation of map
> services from packet services. 
> 
> 	Cheers, 
> 
> 		Tom, KD1UL
> 
> 
> BTW: I run Postgres w/geo coordinates.   If you decide on Postgres, you
> might want
> to consider some other extensions, also.   Referential integrity is a
> bit of a hack
> with Postgres, but it works very well once you get past the weirdnesses
> with
> setting up foreign keys.  Perhaps, a version later than mine
> incorporates this directly:
> I don't know.  Good luck. 
> 
>      
> 
> "Curt Mills, WE7U" wrote:
> 
>>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!"
>>
>>_______________________________________________
>>Xastir-dev mailing list
>>Xastir-dev at xastir.org
> 
> 


-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843