hi
we have a table with some 30M records.
running PG8.1.4. on linux.
when we run with enable_bitmapscan true, PG begins by doing a bitmap index scan
plus a BitmapAnd.
when we run with enable_bitmapscan false, PG finds a better index directly and
chooses a much better plan.
below is some data
Tom Lane wrote:
stig erikson <[EMAIL PROTECTED]> writes:
the question is simply why the planner is not smart enough to skip the bitmap
scan if normal operation is faster.
Probably because it hasn't got good statistics about the distribution of
"bid":
Hi.
There seems to be files missing in the rpm packages for postgresql 8.1.5.
[] rpm -Uvh postgresql*.rpm
error: Failed dependencies:
libpq.so is needed by postgresql-server-8.1.5-2PGDG.i686
libpq.so is needed by postgresql-tcl-1.5.2-4PGDG.i686
i got my rpms from ftp.no.po
Peter Eisentraut wrote:
PostgreSQL Bugs List wrote:
why is this feature important?
having in mind the development of datawarehouses with huge amount of
data (hundreds of millions, or billions of rows in fact tables) every
byte is of importance.
Yet how many applications could make use of the limit
