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

[James Jefferson]

> > My thoughts are that for starters, just the APRS data points received. It
> > might be helpful to ask Steve Dimse what his database fields are, since
> > he has plenty of experience in a SQL database of APRS data.
>
> We have an Xastir user that has a bit of experience there as well
> don't we?  James?

Sure. I'm databasing ~ 2 million packets a day. Running a database with about 
60 queries a second 24/7.

I don't have time today to write too much in depth. But here are the issues I 
see:

Indexes, Indexes, Indexes! If you ever do a query that can't take advantage of 
an index, then the system is as good as dead. With the overhead of the 
databases and normalization between tables, you're looking about more than a 
100 megabytes of data per day. (Heck, the raw stream is at least 50 megabytes 
a day). If you have to do a table scan off of disk (as is the case with a 
machine with not a lot of memory) this starts taking real time.

Figure out what queries you are going to do, and design your tables 
accordingly. For example, on aprsworld.net there is a lastposition table that 
is relatively small (<5 megabytes) and then a full position table that has 
all positions in the database. XAstir would probably want a lastposition 
table, then another table for all of the positions that need to be shown on 
screen. 

Look at the overhead of triggers in Postgres. You may find it nescessary to 
have the parser / inserter daemon handle triggering. In aprsworld.net's 
parser it can fork() a program based on the callsign and SSID of the packet 
it has just inserted. On linux, a signal might be a good way of doing 
triggers. Dunno about how fast other *nixes handle signals.

All for now.

-Jim