Re: row estimate very wrong for array type

That kind of limits the usefulness of aggregating hierarchical dependencies into array columns to avoid enormous join statements. :-|

Re your todo item you mention in this thread:

http://archives.postgresql.org/pgsql-hackers/2010-05/msg01864.php

My C is rusty, but I might have enough understanding of the PG internals to massage pre-existing code... Feel free to message me off list with pointers if you think I might be able to help.

----- Original Message -----
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: Denis de Bernardy <ddebernardy(at)yahoo(dot)com>
> Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
> Sent: Wednesday, May 4, 2011 4:12 PM
> Subject: Re: [PERFORM] row estimate very wrong for array type
>
> Denis de Bernardy <ddebernardy(at)yahoo(dot)com> writes:
>> [ estimates for array && suck ]
>> Might this be a bug in the operator's selectivity, or am I doing
> something wrong?
>
> Array && uses areasel() which is only a stub :-(
>
> In the particular case here it'd be possible to get decent answers
> just by trying the operator against all the MCV-list entries, but it's
> unlikely that that would fix things for enough people to be worth the
> trouble.  Really you'd need to maintain statistics about the element
> values appearing in the array column in order to get useful estimates
> for && queries.  Jan Urbanski did something similar for tsvector columns
> a year or two ago, but nobody's gotten around to doing it for array
> columns.
>
>             regards, tom lane
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>