Thoughts on designing for postgres server performance
dochawk at gmail.com
Sun Jul 19 17:15:06 CEST 2015
My application runs on the loss computer (and eventually tablet) and uses
multiple :memory: SQLite tables for data. Periodically (every few seconds)
a synchronization to postgres server occurs. Each of my customer's
clients/debtors ends up in a single file on the server.
Currently, the application generates an SQLite command, and feeds the
server a command to stash this, and recovers any commands since the last
As livecode can't open an SSL connection to postgres, and can't handle
compound commands to mySQL (even I was willing to risk data with it, which
I'm not), I'm forced to write a simple server.
One possibility is to continue as I am now, stating the commands. The
other is to actually save the values (there are half a dozen per entry for
a couple of tables, and a few dozen/entry for the other)
The serious value in the program to the customer is handling the
dependencies and calculations in the data. If I had data rather than
commands on the server, the server could do some of these calculations, and
send data back. The more I think of it, though, this is suboptimal, at
least for a computer: the local machine can do this near instantly, while
there would be an unacceptable delay waiting for data. On a tablet, delay
right e more tolerable, but I think any modern iPad has the punch to handle
So now that I seem to have convinced myself anyway, the *real* question
that brought me here . . .
If I have, varyingly, a few or dozens of columns per datapoint/record, it's
going to be a significantly lower load on the server (thus less servers) if
I stash/recover a string with a key, timestamp,and userstamp than if I give
it values to play in various columns? the more I think of itI can't see
how this could not be the case, even though the string might be 2-10 times
the data storage (still not much) and larger data to sling back and forth .
It would also make it far easier to rewrite the server in something other
than livecode . . .
Dr. Richard E. Hawkins, Esq.
More information about the use-livecode