On Thu, Mar 1, 2012 at 1:19 AM, Alexander Korotkov <aekorot...@gmail.com>wrote:
> On Thu, Mar 1, 2012 at 1:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> That seems like a pretty narrow, uncommon use-case. Also, to get >> accurate stats for such queries that way, you'd need really enormous >> histograms. I doubt that the existing parameters for histogram size >> will permit meaningful estimation of more than the first array entry >> (since we don't make the histogram any larger than we do for a scalar >> column). >> >> The real point here is that the fact that we're storing btree-style >> stats for arrays is an accident, backed into by having added btree >> comparators for arrays plus analyze.c's habit of applying default >> scalar-oriented analysis functions to any type without an explicit >> typanalyze entry. I don't recall that we ever thought hard about >> it or showed that those stats were worth anything. >> > > OK. I don't object to removing btree stats from arrays. > What do you thinks about pg_stats view in this case? Should it combine > values histogram and array length histogram in single column like do for > MCV and MCELEM? > Btree statistics for arrays and additional statistics slot are removed from attached version of patch. pg_stats view is untouched for while. ------ With best regards, Alexander Korotkov.
arrayanalyze-0.13.patch.gz
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
