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 <t...@sss.pgh.pa.us> > To: Denis de Bernardy <ddeberna...@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 <ddeberna...@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 > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
