Re: Multivariate MCV list vs. statistics target - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Multivariate MCV list vs. statistics target
Date
Msg-id CAEZATCWAs_SzzDAkva2AFd=r4065RYwfey25VwOd1=u3JU7Whg@mail.gmail.com
Whole thread Raw
In response to Re: Multivariate MCV list vs. statistics target  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Multivariate MCV list vs. statistics target
Re: Multivariate MCV list vs. statistics target
List pgsql-hackers
On Thu, 20 Jun 2019 at 23:12, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>
> On Thu, Jun 20, 2019 at 08:08:44AM +0100, Dean Rasheed wrote:
> >On Tue, 18 Jun 2019 at 22:34, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> >>
> >> So I'm thinking we should allow tweaking the statistics for extended
> >> stats, and serialize it in the pg_statistic_ext catalog. Any opinions
> >> why that would be a bad idea?
> >
> >Seems reasonable to me. This might not be the only option we'll ever
> >want to add though, so perhaps a "stxoptions text[]" column along the
> >lines of a relation's reloptions would be the way to go.
>
> I don't know - I kinda dislike the idea of stashing stuff like this into
> text[] arrays unless there's a clear need for such flexibility (i.e.
> vision to have more such options). Which I'm not sure is the case here.
> And we kinda have a precedent in pg_attribute.attstattarget, so I'd use
> the same approach here.
>

Hmm, maybe. I can certainly understand your dislike of using text[].
I'm not sure that we can confidently say that multivariate statistics
won't ever need additional tuning knobs, but I have no idea at the
moment what they might be, and nothing else has come up so far in all
the time spent considering MCV lists and histograms, so maybe this is
OK.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: pg_dump partitions can lead to inconsistent state after restore
Next
From: Peter Eisentraut
Date:
Subject: using explicit_bzero