Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA00249; Tue, 11 Aug 92 13:14:00 -0700
Date: Tue, 11 Aug 92 13:14:00 -0700
Message-Id: <9208112014.AA00249@postgres.Berkeley.EDU>
From: Chris Flatters <cflatter@aoc.nrao.edu>
Subject: Re: query interface
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu

Tommy Thorn (tthorn@daimi.aau.dk) writes:
>    From: Deborah Swanberg <deborah@citi.umich.edu>
> 
>    I'm interested in developing a code structured, rather than
>    string structured, interface to Postgres for submitting queries.
>    It doesn't quite make sense to me that my interface should 
>    have to translate data structures to string, and then that Postgres 
>    should have to translate from string to data structures.
>    A code structured interface would require interfacing at a
>    lower level to Postgres.
> 
>    Comments?
> 
> Why bother? Having a well defined interface, like the query strings,
> really buys you a lot, for debugging and ease of program changes.
> The cycles wasted in assembling a command and parsing it is not an
> issue on a modern workstation.

Firstly, the overhead of assembling a command can be a serious overhead
in some applications.  Suppose that we have an uncalibrated scientific
data set stored in a POSTGRES table.  For the sake of argument suppose
that each item contains one measurement stored a single real number and
the other fields record the time at which the measurement was taken and
other information that identifies the measurement.  In order to calibrate
the data we must multiply the real number by an externally derived number
that varies from measurement from measurement.  The straightforward way
of doing this requires generating a query string for every data item.  If
there are very many data items the cost of doing this can be prohibitive
(converting numeric data to text is very expensive) and some scientific
applications can involve 1e5 or more data items.

The alternative is to use a binary copy to copy the calibration factors
into a seperate POSTGRES table and apply them to the original data,
generating a new POSTGRES table.  This may be ruled out in some cases
by the size of the data sets (some scientific datasets may have storage
requirements of the order of a gigabyte or more).

Secondly, converting floating-point numbers to text and back again
can incurr a loss of precision.  This may be critical in some scientific
applications.  Fortunately this is not a problem on machines that
implement IEEE-754 binary floating-point arithmetic.

	Chris Flatters
	cflatter@nrao.edu