From: | Marco Colli <collimarco91(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Statistics on array values |
Date: | 2020-02-02 18:55:59 |
Message-ID: | CAFvCgN7J46PwvO_cC4_AxsCosjQ9GqWi_kfmC8d+oQbS_7omSg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Sorry, I don't understand your exact question about pg_stats. In any case I
cannot make strict assumptions about data, because that greatly varies from
project to project (it's a SaaS) and over time. To give an idea the table
has some tens of millions of rows, each project has from a few thousands to
a few millions of rows and each project has its own tags that the customer
can define (unlimited tags for each row, but usually only 1 - 10 actually
used)
Il Dom 2 Feb 2020, 19:32 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> ha scritto:
> Marco Colli <collimarco91(at)gmail(dot)com> writes:
> > Unfortunately I don't get actual improvements. I use PG 11 and I run the
> > following commands:
> > ALTER TABLE subscriptions ALTER tags SET STATISTICS 1000;
> > ANALYZE subscriptions;
> > However the bias remains pretty much the same (slightly worse after). Any
> > idea?
>
> So what have you got in the pg_stats fields I asked about?
> How big is this table anyway (how many rows, how many different tag
> values)?
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Benny Kramek | 2020-02-03 20:38:15 | Slow performance with trivial self-joins |
Previous Message | Tom Lane | 2020-02-02 18:32:02 | Re: Statistics on array values |