Cristian Gafton <[EMAIL PROTECTED]> writes: > On Sun, 16 Mar 2008, Tom Lane wrote: >> While thinking about your report I was considering having VACUUM and >> ANALYZE always set relpages to at least 1. Then seeing relpages=0 >> would indeed indicate a never-analyzed table, whereas relpages=1 >> when physical table size is zero could be taken to indicate that >> we should trust the table to be really empty. I'm not sure though >> whether this sort of convention would confuse any existing code.
> If having a discrepancy between relpages and table size is a concern, > could relpages be a negative value to mark a non-analyzed table? No, the value is really a uint32, though we don't declare it that way for lack of having any such SQL type :-(. (uint32)-1 is just as legal a value as 1, though perhaps a lot less likely. Anyway, client code looking at the column is probably more likely to get confused by a negative value for relpages than by a value that doesn't match underlying reality (which it can't easily see anyway). >> Could you confirm that your problem cases are actually caused by this >> effect and not something else? > Yes, confirmed. The runaway queries all are joining against an empty > temporary table. Good, just wanted to be sure. If there are not objections, I'll put in the at-least-1 hack. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers