Re: [HACKERS] Enhanced containment selectivity function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Enhanced containment selectivity function
Date: 2006-05-12 13:33:45
Message-ID: 23644.1147440825@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Matteo Beccati <php(at)beccati(dot)com> writes:
> It was a big surprise having no improvements at all in the query I used
> for all my previous tests, until I found out that the test against
> histogram values was removed by Tom. I strongly think it should be
> reintroduced: ltree columns are likely to have a unique constraint and
> the current ltreeparentsel function will behave just like contsel in
> these cases.

The histogram values seem completely meaningless in this context ---
for containment purposes, they are just ten or so randomly chosen
values. I don't believe that the estimator works better with them.
Certainly, whether the column is unique or not is totally irrelevant
to whether they are representative.

What would seem saner to me is to add a datatype-specific analyze
function that collects some statistics that are actually relevant
to containment, and then make use of those in the estimator.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-05-12 13:46:21 Re: any, anyelement, and anyarray
Previous Message Jaime Casanova 2006-05-12 13:00:13 Re: BEGIN inside transaction should be an error

Browse pgsql-patches by date

  From Date Subject
Next Message Matteo Beccati 2006-05-12 13:56:03 Re: [HACKERS] Enhanced containment selectivity function
Previous Message Jaime Casanova 2006-05-12 13:00:13 Re: BEGIN inside transaction should be an error