Well, then you'll probably want to get the list of column names via a separate query, store those in an array (e.g. "@colnames")...

No you don't. Check out the property NAME of the statement handles in the DBI docs. It fetches and stores those column names into an array, when you execute the query. This property contains an array ref to it.

my $sth = $dbh->prepare("SELECT * FROM sometable");
my $colnames = $sth->{NAME};
while (my $rowref = $sth->fetchrow_arrayref ) {
    @rowhash{@$colnames} = @$rowref;
    ...
}
[download]

However, DBI being highly optimized as it is, I don't expect any speed improvement over fetching the hashref.

Why the need for a hash anyway? It's not ordered. So, keeping the names and data as two arrays, holds more information for you, than just the hash on its own does: the column order. I would believe that for printing, the order is very important. To loop through the arrays side by side, loop through the array index (for either array, they're the same size).

You can always still map the field names to column numbers, the inverse of the array @$colnames, in a separate hash — and you need to do that only once:

my %colcolumn; @colcolumn{@$colnames} = 0 .. $#$colnames;
[download]

Stil, I don't expect all this mucking about to perform any miracles. Otherwise, Tim Bunce and co. would really have had to have been messing about. I don't think so.