From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Cristian Gafton <gafton(at)rpath(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Single table forcing sequential scans on query plans |
Date: | 2008-03-17 04:45:39 |
Message-ID: | 24059.1205729139@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Cristian Gafton <gafton(at)rpath(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2008-03-17 05:24:17 | Re: [0/4] Proposal of SE-PostgreSQL patches |
Previous Message | Kohei KaiGai | 2008-03-17 04:31:06 | [4/4] Proposal of SE-PostgreSQL patches |