Re: Collect frequency statistics for arrays
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Nathan Boley <npboley@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-01T14:57:17Z
Lists: pgsql-hackers
Attachments
- arrayanalyze-0.13.patch.gz (application/x-gzip) patch
On Thu, Mar 1, 2012 at 1:19 AM, Alexander Korotkov <aekorotkov@gmail.com>wrote: > On Thu, Mar 1, 2012 at 1:09 AM, Tom Lane <tgl@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.