Re: Composite fields and the query planner

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Composite fields and the query planner
Дата
Msg-id 1222.1367762815@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Composite fields and the query planner  (Steve Rogerson <steve.pg@yewtc.demon.co.uk>)
Ответы Re: Composite fields and the query planner  (Steve Rogerson <steve.pg@yewtc.demon.co.uk>)
Re: Composite fields and the query planner  (Steve Rogerson <steve.pg@yewtc.demon.co.uk>)
Список pgsql-general
Steve Rogerson <steve.pg@yewtc.demon.co.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


В списке pgsql-general по дате отправления:

Предыдущее
От: Steve Rogerson
Дата:
Сообщение: Composite fields and the query planner
Следующее
От: Yuriy Rusinov
Дата:
Сообщение: Re: SPI_execute_with_args call