On 7 April 2011 08:10, Thom Brown wrote:
> On 7 April 2011 07:37, Tom Lane wrote:
>> Thom Brown writes:
>>> On 6 April 2011 05:44, Tom Lane wrote:
It looks like the index predicate expression isn't getting the right
collation assigned, so predtest.c decides the query doesn't imply the
On 7 April 2011 07:37, Tom Lane wrote:
> Thom Brown writes:
>> On 6 April 2011 05:44, Tom Lane wrote:
>>> It looks like the index predicate expression isn't getting the right
>>> collation assigned, so predtest.c decides the query doesn't imply the
>>> index's predicate. Too tired to look into
Thom Brown writes:
> On 6 April 2011 05:44, Tom Lane wrote:
>> It looks like the index predicate expression isn't getting the right
>> collation assigned, so predtest.c decides the query doesn't imply the
>> index's predicate. Too tired to look into exactly why right now, but
>> it's clearly bou
On 6 April 2011 00:02, Kenneth Marshall wrote:
> The stats seem off. Are you certain that an analyze has run?
>
> Cheers,
> Ken
>
Yes, an ANALYZE was definitely run against the table.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: h
On 6 April 2011 05:44, Tom Lane wrote:
> Thom Brown writes:
>> The index doesn't get used. There's probably a logical explanation,
>> which is what I'm curious about.
>
> Er ... it's broken?
>
> It looks like the index predicate expression isn't getting the right
> collation assigned, so predtes
Thom Brown writes:
> The index doesn't get used. There's probably a logical explanation,
> which is what I'm curious about.
Er ... it's broken?
It looks like the index predicate expression isn't getting the right
collation assigned, so predtest.c decides the query doesn't imply the
index's pred
On 06/04/11 11:40, Mark Kirkwood wrote:
On 06/04/11 11:31, Scott Marlowe wrote:
On Tue, Apr 5, 2011 at 4:35 PM, Thom Brown wrote:
I'm using 9.1dev.
SNIP
DROP INDEX indextest_stuff;
CREATE INDEX indextest_stuff ON indextest(stuff) WHERE stuff = 'bark';
postgres=# explain analyze select * f
On 06/04/11 11:31, Scott Marlowe wrote:
On Tue, Apr 5, 2011 at 4:35 PM, Thom Brown wrote:
I'm using 9.1dev.
SNIP
DROP INDEX indextest_stuff;
CREATE INDEX indextest_stuff ON indextest(stuff) WHERE stuff = 'bark';
postgres=# explain analyze select * from indextest where stuff = 'bark';
On Tue, Apr 5, 2011 at 4:35 PM, Thom Brown wrote:
> I'm using 9.1dev.
SNIP
> DROP INDEX indextest_stuff;
>
> CREATE INDEX indextest_stuff ON indextest(stuff) WHERE stuff = 'bark';
>
> postgres=# explain analyze select * from indextest where stuff = 'bark';
>
On Tue, Apr 05, 2011 at 11:35:29PM +0100, Thom Brown wrote:
> I'm using 9.1dev.
>
> Could someone explain the following behaviour?
>
> -- create a test table
> CREATE TABLE indextest (id serial, stuff text);
>
> -- insert loads of values with intermittent sets of less common values
> INSERT INTO
I'm using 9.1dev.
Could someone explain the following behaviour?
-- create a test table
CREATE TABLE indextest (id serial, stuff text);
-- insert loads of values with intermittent sets of less common values
INSERT INTO indextest (stuff) SELECT 'meow' FROM generate_series (1,100);
INSERT INTO
11 matches
Mail list logo