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
messageme off list with pointers if you think I might be able to help.
----- Original Message -----
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Denis de Bernardy <ddebernardy@yahoo.com>
> Cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
> Sent: Wednesday, May 4, 2011 4:12 PM
> Subject: Re: [PERFORM] row estimate very wrong for array type
>
> Denis de Bernardy <ddebernardy@yahoo.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
