Lists: | pgsql-hackers |
---|
From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | gincostestimate |
Date: | 2011-04-08 21:07:06 |
Message-ID: | BANLkTinz2do3EqWO9RH66bY2FBOmL=uSoA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Dear Hackers,
A gin index created on an initially empty table will never get used
until the table is vacuumed, which for a table with no update or
delete activity could be forever unless someone manually intervenes.
The problem is that numEntries in src/backend/utils/adt/selfuncs.c is
zero and eventually causes a division by zero and a cost estimate of
nan.
The code below does not save the day, because nTotalPages and
nEntryPages are 2 and 1 respectively when an index is created on an
empty table, or when an indexed table is truncated.
if (ginStats.nTotalPages == 0 || ginStats.nEntryPages == 0)
{
numEntryPages = numPages;
numDataPages = 0;
numEntries = numTuples; /* bogus, but no other info available */
}
I don't know what the solution is. Simply setting numEntries to 1 if
ginStats.nEntries zero solves this particular problem, but I don't
know what other consequences it might have.
Cheers,
Jeff
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gincostestimate |
Date: | 2011-04-21 23:27:22 |
Message-ID: | 4450.1303428442@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> The problem is that numEntries in src/backend/utils/adt/selfuncs.c is
> zero and eventually causes a division by zero and a cost estimate of
> nan.
> ...
> I don't know what the solution is. Simply setting numEntries to 1 if
> ginStats.nEntries zero solves this particular problem, but I don't
> know what other consequences it might have.
Yeah, I think clamping numEntries to a minimum value of 1 is a
reasonable thing to do. Will fix.
regards, tom lane