Re: Trying to track down weird query stalls
От | dan@sidhe.org |
---|---|
Тема | Re: Trying to track down weird query stalls |
Дата | |
Msg-id | 61646.199.172.169.32.1238446195.squirrel@localhost обсуждение исходный текст |
Ответ на | Re: Trying to track down weird query stalls (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Trying to track down weird query stalls
|
Список | pgsql-performance |
> dan@sidhe.org escribió: > >> where libinstance.libdate <= 1238445044 >> and libinstance.enddate > 1238445044 >> and libinstance.libinstanceid = libobject.libinstanceid >> and libinstance.architecture = ? > > How are you generating the explain? My bet is that you're just > substituting a literal in the architecture condition, but if the driver > is smart then maybe it's preparating the query beforehand. You'll get a > different plan in that case. I don't think so. Perl's DBI is involved, but the statement's in a variable. The code in question is: if ($db->{debug}) { $db->debug("SQL is: $sql\n"); my $rows = $db->{dbh}->selectall_arrayref("explain analyze $sql", undef, $db->{arch}, $db->{basebranch}); foreach my $row (@$rows) { $db->debug(join(" ", @$row). "\n"); } $db->debug_stamp("Initial query done\n"); } $rows = $db->{dbh}->selectall_arrayref($sql, undef, $db->{arch}, $db->{basebranch}); There's no transform of the sql variable between the two statements, just a quick loop over the returned rows from the explain analyze to print them out. (I did try to make sure that the debugging bits were done the same way as the mainline code, but I may have bobbled something) -Dan
В списке pgsql-performance по дате отправления: