Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group