Efficiency vs. code bloat for SELECT wrappers

From: Colin Wetherbee <cww(at)denterprises(dot)org>
To: PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Efficiency vs. code bloat for SELECT wrappers
Date: 2007-12-16 23:31:56
Message-ID: 4765B56C.3040801@denterprises.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greetings.

I am working on a PostgreSQL-backed mod_perl web application that's just
in its infancy.

Let's say I have a users table that holds about 15 columns of data about
each user.

If I write one Perl sub for each operation on the table (e.g. one that
gets the username and password hash, another that gets the last name and
first name, etc.), there will be a whole lot of subs, each of which
performs one very specific task.

If I write one larger Perl sub that grabs the whole row, and then I deal
with the contents of the row in Perl, ignoring columns as I please, it
will require fewer subs and, in turn, imply cleaner code.

My concern is that I don't know what efficiency I would be forfeiting on
the PostgreSQL side of the application by always querying entire rows if
my transaction occurs entirely within a single table. Of course, I
would want to handle more complicated JOINs and other more intensive
operations on the PostgreSQL side.

I don't think the application will ever store a tuple larger than about
512 bytes in any table, so the network speed wouldn't really come into play.

Thanks.

Colin

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-12-16 23:45:46 Re: Efficiency vs. code bloat for SELECT wrappers
Previous Message Tom Lane 2007-12-16 17:08:24 Re: Recovering data via raw table and field separators