From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Steve Rogerson <steve(dot)pg(at)yewtc(dot)demon(dot)co(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Composite fields and the query planner |
Date: | 2013-05-05 14:06:55 |
Message-ID: | 1222.1367762815@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Steve Rogerson <steve(dot)pg(at)yewtc(dot)demon(dot)co(dot)uk> writes:
> I'm seeing a problem with the query planner not doing what's expected, and I
> think it is because we are using composite fields. Here is a stripped down
> example.
> create type type1 as ( part1 varchar, part2 varchar);
> create table table1 (field1 type1, field2 varchar);
> create function get_part1(type1) returns varchar as $$ select ($1).part1 $$
> language sql;
> create index i1 on table1 (get_part1(field1));
> create index i2 on table1 (field2);
I tested this example in HEAD and 9.0.x and didn't see any particular
problem with rowcount estimates for the get_part1() expression. You
do have to have the i1 index in place when the table is analyzed, else
ANALYZE won't collect any stats about the expression.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Yuriy Rusinov | 2013-05-05 20:22:27 | Re: SPI_execute_with_args call |
Previous Message | Steve Rogerson | 2013-05-05 13:05:26 | Composite fields and the query planner |