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@xxxxxxxxxxxxx> > To: Denis de Bernardy <ddebernardy@xxxxxxxxx> > Cc: "pgsql-performance@xxxxxxxxxxxxxx" <pgsql-performance@xxxxxxxxxxxxxx> > Sent: Wednesday, May 4, 2011 4:12 PM > Subject: Re: row estimate very wrong for array type > > Denis de Bernardy <ddebernardy@xxxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
