On Tue, Dec 14, 2004 at 02:54:39PM +0900, [EMAIL PROTECTED] wrote: > Hi. > > >> >http://search.cpan.org/~mergl/pgsql_perl5-1.9.0/ > >> Well,newer Pg.pm will be found here: > >> > >> http://gborg.postgresql.org/project/pgperl/projdisplay.php > > >> But > >> >> I'm working with Perl and PostgreSQL using DBD::Pg and Pg and > >> >> noticied that Pg is 40% faster than DBD::Pg. > >> I can't belive this before testing by myself. > >> Is there anymore information about those bench mark? > > > > I can, for it all depends on how the benchmarking is done, and I'd > > have to say, who cares if Pg is 40% faster?
I do! The DBI is designed to be very fast. Speed should never be a reason to use something else. If Pg is really 40% faster then there are problems in the DBD::Pg code. > I benchmarked them (Pg and DBD::Pg) 2 or 3 years ago. > At that time, DBD::Pg even slightly faster than Pg. > #The result can be found this book (sorry but it is written in Japanese :)) > # http://www.amazon.co.jp/exec/obidos/ASIN/4756140580/250-7597458-9918646 > > I think "it all depends on how the benchmarking is done" too. > #Maybe I should say "trust" not "believe". Assuming that the "40% faster" relates mainly to fetching then here's a quick review of the relevant code... The Pg extension just does this to fetch a row: int col = 0; EXTEND(sp, cols); while (col < cols) { if (PQgetisnull(res->result, res->row, col)) { PUSHs(&PL_sv_undef); } else { char *val = PQgetvalue(res->result, res->row, col); PUSHs(sv_2mortal((SV*)newSVpv(val, 0))); } ++col; } ++res->row; While the DBD::Pg extension does: for(i = 0; i < num_fields; ++i) { SV *sv = AvARRAY(av)[i]; if (PQgetisnull(imp_sth->result, imp_sth->cur_tuple, i)) { sv_setsv(sv, &sv_undef); That would be significantly faster as: SvROK(sv) ? sv_unref(sv) : SvOK_off(sv); } else { value = (char*)PQgetvalue(imp_sth->result, imp_sth->cur_tuple, i); pg_type = PQftype(imp_sth->result, i); type_info = pg_type_data(pg_type); Types don't vary between rows so the PQftype() and pg_type_data() calls could be factored out of this inner-inner loop. if (type_info) type_info->dequote(value, &value_len); /* dequote in place */ else value_len = strlen(value); if (type_info && (type_info->type_id == BOOLOID) && imp_dbh->pg_bool_tf) { *value = (*value == '1') ? 't' : 'f'; } sv_setpvn(sv, value, value_len); if (type_info && (type_info->type_id == BPCHAROID) && chopblanks) { ... } #ifdef is_utf8_string /* XXX Under what circumstances is type_info NULL? */ if (imp_dbh->pg_enable_utf8 && type_info) { SvUTF8_off(sv); switch(type_info->type_id) { case CHAROID: case TEXTOID: case BPCHAROID: case VARCHAROID: if (is_high_bit_set(value) && is_utf8_string(value, value_len)) { SvUTF8_on(sv); } } } #endif is_utf8_string() is defined for perl 5.8.x. That'll slow down fetching of strings. Especially if any are long or have high bits set. It ought not to be default behaviour as it's playing 'guessing games' with the data without the applications permission. } } Tim. p.s. If anyone wants to discuss the code more then please change dbi-users to dbi-dev in the CC list. Thanks.