On 5/9/11 9:59 , Kevin Grittner wrote:
You don't need to do that; you can specify an opclass for the index
to tell it that you don't want to order by the normal collation, but
rather in a way which will allow the index to be useful for pattern
matching:
http://www.postgresql.org/docs/9.0/intera
Marcus Engene wrote:
> On 5/9/11 8:57 , Kevin Grittner wrote:
>>
>> That could be a difference is collations. What do you get from
>> the query on this page for each database?:
>>
>> http://wiki.postgresql.org/wiki/Server_Configuration
> There's indeed a different collation. Why is this affecti
On 5/9/11 8:57 , Kevin Grittner wrote:
That could be a difference is collations. What do you get from the
query on this page for each database?:
http://wiki.postgresql.org/wiki/Server_Configuration
-Kevin
There's indeed a different collation. Why is this affecting? Can i force
a column
Marcus Engene wrote:
> I have a table with a few million rows and this index:
> CREATE INDEX bond_item_common_x7 ON bond_item_common
> ((lower(original_filename)));
> Dropping the wildcard for the like, both databases uses the index.
>
> Is there a way to convince Postgres to try not to do f
Marcus Engene writes:
> There are about 2M rows on bonddump and 4M rows on bond90.
> bonddump is on a 8MB RAM machine, bond90 is on a 72MB RAM machine.
> The table is analyzed properly both places.
I'll bet one database was initialized in C locale and the other not.
regar
Dear list,
I have a table with a few million rows and this index:
CREATE INDEX bond_item_common_x7 ON bond_item_common
((lower(original_filename)));
There are about 2M rows on bonddump and 4M rows on bond90.
bonddump is on a 8MB RAM machine, bond90 is on a 72MB RAM machine.
The table is anal
