On 06.06.2011 12:43, Heikki Linnakangas wrote:
Also, even when safe, it's not clear that the transformation is always a
win. The left-hand expression could be expensive, in which case having
to evaluate it multiple times could hurt performance. Maybe yo
Sorry, hit "send" too early.
Maybe you c
On 15.03.2011 14:30, Chetan Suttraway wrote:
On Sun, Feb 27, 2011 at 2:43 AM, Josh Berkus wrote:
On 2/25/11 5:31 AM, Sam Wong wrote:
I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
field used the index correctly, but not "LIKE ANY (...)". Would that be a
bug?
No, it
On Tue, Mar 15, 2011 at 8:30 AM, Chetan Suttraway
wrote:
> On Sun, Feb 27, 2011 at 2:43 AM, Josh Berkus wrote:
>>
>> On 2/25/11 5:31 AM, Sam Wong wrote:
>> > I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
>> > field used the index correctly, but not "LIKE ANY (...)". Woul
On Sun, Feb 27, 2011 at 2:43 AM, Josh Berkus wrote:
> On 2/25/11 5:31 AM, Sam Wong wrote:
> > I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
> > field used the index correctly, but not "LIKE ANY (...)". Would that be a
> > bug?
>
> No, it would be a TODO. This is a known
On 2/25/11 5:31 AM, Sam Wong wrote:
> I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
> field used the index correctly, but not "LIKE ANY (...)". Would that be a
> bug?
No, it would be a TODO. This is a known limitation; it needs some
clever code to make it work, and nobod
Russell Smith <[EMAIL PROTECTED]> writes:
> On Sun, 13 Mar 2005 04:40 pm, Tom Pfeifer wrote:
>> I get really slow repoonse times when using the following select statement
>> (About 20 seconds).
>> maach=# explain select * from tst where tst_id = 639246;
> Before 8.0, bigint would not use an ind
On Sun, 13 Mar 2005 04:40 pm, Tom Pfeifer wrote:
> Hello,
>
>
> My version of Postgresql is 7.4.3.
> I have a simple table with 2 indexes:
> Table "public.tst"
> Column | Type | Modifiers
> +
Arshavir,
> Thanks for all the replies. It actually has to do with the locales. The
> db where the index gets used is running on C vs the the other one that
> uses en_US.UTF-8. I guess the db with the wrong locale will need to be
> waxed and recreated with correct locale settings. I wonder if ther
On Fri, 19 Nov 2004, Arshavir Grigorian wrote:
> Hi,
>
> I have a query that when run on similar tables in 2 different databases
> either uses the index on the column (primary key) in the where clause or
> does a full table scan. The structure of the tables is the same, except
> that the table whe
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
> I have a query that when run on similar tables in 2 different databases
> either uses the index on the column (primary key) in the where clause or
> does a full table scan. The structure of the tables is the same, except
> that the table where the
Thanks for all the replies. It actually has to do with the locales. The
db where the index gets used is running on C vs the the other one that
uses en_US.UTF-8. I guess the db with the wrong locale will need to be
waxed and recreated with correct locale settings. I wonder if there are
any plans
Arshavir,
> I have a query that when run on similar tables in 2 different databases
> either uses the index on the column (primary key) in the where clause or
> does a full table scan. The structure of the tables is the same, except
> that the table where the index does not get used has an extra m
On Fri, Nov 19, 2004 at 02:18:55PM -0500, Arshavir Grigorian wrote:
> The 2 boxes where these database run are very different (Sparc with scsi
> disks and 2G RAM running Solaris 8 AND a PC with 128M RAM running and an
> IDE drive running Linux RH9 2.4.20-20.9). I am not sure why that would
> mak
13 matches
Mail list logo
