Re: New Zealand Postgis DBA job vacancy - Mailing list pgsql-general

From Bexley Hall
Subject Re: New Zealand Postgis DBA job vacancy
Date
Msg-id 50DB7B69.4010806@yahoo.com
Whole thread Raw
In response to New Zealand Postgis DBA job vacancy  (pcreso@pcreso.com)
Responses Re: New Zealand Postgis DBA job vacancy  (Martin Gainty <mgainty@hotmail.com>)
List pgsql-general
Hi Martin,

[apologies if msg reference chain mangled -- forgot to Cc list  <:-( ]

On 12/26/2012 2:04 PM, Martin Gainty wrote:

> most of us in the US choose to be *delightfully ignorant* of
> anything that doesnt fit into our 30 seconds (or less) lifestyle

"30 seconds"?  Seems an *eternity* for most of the folks I meet!
(i.e., if you haven't answered your cell phone by the *second*
ring, the followup text message -- "Where are you?" -- is *delivered*
in that time frame!)

Sheesh!  How can people live like this??  Can you spell "short leash"?

> metric system requires rudimentary math skills instead of
> entertainment so we collectively choose not to think of such things

Thinking (entirely) *in* metric doesn't.  The problem is working
with *both*, simultaneously, requires some mental agility.

Nearby, we have one of the few (only?) stretches of roadway that
is marked in metric units (actually, I haven't driven it in a while
and vaguely recall something about RE-marking it in "conventional"
units).  To most folks, it is a disturbing experience as they aren't
accustomed to thinking in these.  ("No, that's not 100MPH but
100kmph... big difference!")

OTOH, working entirely within the "english" system is significantly
taxing if you want to deal with more than one unit of measure at
a time.  Feet/miles/yards/inches.  Gills/gallons/pints.  etc.

I'm tickled that I've got a 1/3C measuring cup and a 1/4T (not 't')
measuring spoon (I bake a lot).  Otherwise, it's a real chore
hitting some of these "odd" measurements!

[The idea of *weighing* ingredients is anathema to me -- and I
can't imagine it would be as expedient as using "fixed volumes"!]

> I spent 3 months outside the US this year and was *forced* to use
> my brain to convert petrol containers from liters to US gallons
> It was nice to be able to come back to the US to put your brain
> *in park* and let the big brains in the statehouses and Washington
> tell us -what to do and -provide us the funding to do their bidding
> at least until 1 Jan 2013!

> so...why doesn't Postgres port to embedded systems?

IME, it requires lots of resources (the vast majority of embedded
systems are resource starved -- resources == $$ and when you are
selling things in volume, every penny saved adds up quickly!).
Lots of MIPS, lots of RAM -- even the code footprint is "significant".

OTOH, (again, IME) designing with the "relational table" construct
makes coding a very different experience!  Already being biased
in favor of table-driven algorithms, I took this opportunity to
move all the "const" tables out of my executables and into the
DBMS (which takes a performance hit but keeps the code much more
mutable).  I've gone so far as to hide the filesystem from the
applications -- objects that would have typically resided in
ad hoc files are now stored in structured tables (eliminates
the need to write lots of special parsers to be able to impose
structure on what would otherwise be unstructured "bytes")

[This last issue owes nothing to pgsql, though, as any RDBMS
can provide that structure/capability]

<shrug>  We'll see... it's been a learning experience (make
one to throw away)

--don


pgsql-general by date:

Previous
From: Bexley Hall
Date:
Subject: Re: New Zealand Postgis DBA job vacancy
Next
From: Amit Kapila
Date:
Subject: Re: Cursor fetch Problem.