Re: Composite fields and the query planner

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

In response to

Responses

Browse pgsql-general by date

  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