On 6/22/11 11:42 , Greg Smith wrote:
On 06/22/2011 05:27 PM, Marcus Engene wrote:
I have some tables with bitmask integers. Set bits are the
interesting ones. Usually they are sparse.
If it's sparse, create a partial index that just includes rows where
the bit is set:
On 07/03/2011 06:21 AM, Magnus Hagander wrote:
I was at one point told that *all* of infinite cache would be
submitted to the community, but it was in need of some cleanup
first.
I'm not sure what kind of cleanup would be involved, but we had some
problems with index corruption that wasn't
I am trying to perform a bulkload of 1 crore rows using copy of row width
1000, but the transaction logs keeps getting huge space, is there a easy way
to do it and avoid the transaction logs
On 07/05/2011 10:42 AM, shouvik basu wrote:
I am trying to perform a bulkload of 1 crore rows using copy of row
width 1000, but the transaction logs keeps getting huge space, is
there a easy way to do it and avoid the transaction logs
If you're using the built-in streaming replication or
On 07/05/2011 06:15 AM, Marcus Engene wrote:
Though partial index solved another problem. Usually I'm a little bit
annoyed with the optimizer and the developers religious fix the
planner instead of index hints. I must say that I'm willing to
reconsider my usual stance to that.
We have a
I have a query that uses ORDER BY and LIMIT to get a set of image data
rows that match a given tag. When both ORDER BY and LIMIT are included
for some reason the planner chooses a very slow query plan. Dropping
one or the other results in a much faster query going from 4+ seconds -
30 ms.
