Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL - Mailing list pgsql-hackers

At 09:55 PM 2/2/00 -0500, Tom Lane wrote:

>There is also a nontrivial performance penalty that would be paid
>for reversing this default, because then every ordinary SQL query
>would suffer the overhead of looking to see whether there are
>child tables for each table named in the query.  That *really*
>doesn't strike me as a good idea.

Thank you for pointing this out, because my first reaction to
the proposal was "what's the overhead for SQL users"?

Given the stated goals of becoming a fast, efficient, reliable
SQL engine, this has to be a crucial consideration.

On the other hand, as someone who once made his living off his 
designed and implemented optimizing multi-language, multi-platform
compiler technology...is it entirely out of the question to 
consider more greatly abstracting the language (gram.y/analyze.c)
and backend (optimizer and executor) interfaces so more than one
front-end could exist (even if only in experimental and research
environments)?  Along with front-end specific versions of libpq?

These front-ends wouldn't necessarily need to be supported by
the mainstream PG development group, except to support a defined
and sufficiently abstract interface to the optimization/planning and
executing guts of the system so that folks could mess around to
their heart's content.  And bear the burden of doing so if they
pick up users :)

Just a thought...

>> I would propose that that anytime you do a SELECT * from a base table
>> that you would get back the full rows from those sub tables.
>
>Frankly: ugh.  This doesn't square with *my* ideas of object
>inheritance.

Nor mine, in fact the stuff I've seen about primitive OO in databases
make me thing the folks just don't get it.

Not to mention that I'm not convinced that "getting it" is worth it.  OO
fits some paradigms, not others, when programming in the large.  And 
most database stuff is really programming in the small (the query parts,
the data is often huge, of course).  The notion of asking a query, as
in (say) psql is more related to the notion of typing a few lines at
BASIC than the notion of writing a few million lines of integrated 
code.  In database design, even more so than in conventional programming,
it is the data model that reigns supreme and the actual size tends to
be manageable, though the models themselves can be very complex.

I offer this as a reason why commercial DB users are more concerned 
with things like performance, scalability, and the like than with
reworking of the RDBMS paradigm.  Complaints about queries seem to
place heavy emphasis on "why they are slow", and the OO paradigm
doesn't help here.  I'm not certain that psuedo-OO features help.

One reason I raise the issue of possible multiple front-ends (or making
it easy for folks to make there own by making the parser->optimizer/backend
interface more general) is that this whole area would seem to be one 
that begs for RESEARCH and experimentalism.

The reality, AFAIK, is that in the crucible of commercial use, real
OO databases and thinking simply haven't penetrated.  

Nor is Postgres written in C++ :)  (GOOD decision to abandon that
thought, IMO, though at the moment I'm working on C++ tools for
my current client).



>Again, I think you've got the default backwards.  I remind you also
>of something we've been beating on Peter about: psql is an application
>scripting tool, so you don't get to redefine its behavior at whim,
>anymore than you can change libpq's API at whim.

Yeah, this is VERY important.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.