On Oct 10, 2009, at 10:40 AM, Mark Mielke wrote:
On 10/10/2009 01:14 AM, tsuraan wrote:
The most significant impact is that it takes up twice as much space,
including the primary key index. This means fewer entries per block,
which means slower scans and/or more blocks to navigate through.
Sti
On Fri, Oct 16, 2009 at 4:36 PM, Vikul Khosla wrote:
> In Oracle, we replaced the B-Tree Indexes with Bitmap indexes and saw
> performance go
> through the roof. I know Postgres does not have Bitmap indexes,
> but is there a reasonable alternative to boost performance in situations
> where low car
Folks,
We have just migrated from Oracle to PG.
We have a database that has approx 3 mil rows and one of the columns has a
cardinality
of only 0.1% (3000 unique values).
We have to issue several queries that use this low cardinality column in a
WHERE clause
as well as see this column particip
decibel escribió:
> >If you want it to be seemless and fully optimal, you would
> >introduce a new int256 type (or whatever the name of the type you
> >are trying to represent). Adding new types to PostgreSQL is not
> >that hard. This would allow queries (=, <>, <, >) as well.
>
> If you want an
On Oct 10, 2009, at 10:40 AM, Mark Mielke wrote:
On 10/10/2009 01:14 AM, tsuraan wrote:
The most significant impact is that it takes up twice as much space,
including the primary key index. This means fewer entries per block,
which means slower scans and/or more blocks to navigate through.
Sti
