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
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?
Here is my table and index:
CREATE TABLE shipment_lookup
(
shipment_id text NOT NULL,
lookup text NOT NULL
);
CREATE INDEX shipment_lookup
Hello pals, I have the following table in Postgresql 8.0.1
Mydb# \d geoip_block
Table "public.geoip_block"
Column| Type | Modifiers
-++---
locid | bigint |
start_block | inet |
end_block | inet |
mydb# explain analyze select locid from geoip_blo
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
> +
Hello,
My version of Postgresql is 7.4.3.
I have a simple table with 2 indexes:
Table "public.tst"
Column | Type | Modifiers
+-+-
tst_id | bigint
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
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 where the index does not get used has an extra million
rows
17 matches
Mail list logo
