rds to be returned, we
would expect this not to happen so soon.
- Why is most_common_* not filled when there are only 3 distinct values?
Feike Steenbergen
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Hi, thanks for having a look and thinking with us
On 25 March 2015 at 13:45, Tomas Vondra wrote:
> Can you post results for this query?
>
> SELECT stats, COUNT(*) FROM print_list group by 1
status | count
+-
ERROR | 159
PREPARED | 10162
PRINT
I'm posting this as I am trying to understand what has happened.
TLDR: The problem seems to be fixed now.
By bumping the statistics_target we see that most_common_vals is
having its contents filled more often, causing way better estimates:
attname| status
inherited
On 25 March 2015 at 19:07, Jeff Janes wrote:
> Also, I doubt that that is the problem in the first place. If you collect a
> sample of 30,000 (which the default target size of 100 does), and the
> frequency of the second most common is really 0.00307333 at the time you
> sampled it, you would ex
On 25 March 2015 at 22:45, Jeff Janes wrote:
> How can the avg_width be 4 when the vast majority of entries are 7
> characters long?
The datatype is an enum, as I understand it, an enum type always
occupies 4 bytes
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
Sorry, didn't respond to all your questions:
> What version of PostgreSQL are running? 'select version();'
PostgreSQL 9.3.4 on x86_64-pc-linux-gnu, compiled by gcc-4.6.real
(Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
> What do you get when to do "analyze verbose print_list"?
# analyze verbose
On 23 January 2017 at 17:55, Gabriel Dodan wrote:
>
> BUT if I run a trivial select on both servers, on a similar table, the
select
> perform much much better on second server!
You're comparing two very different systems it seems, therefore you might be
looking at difference in the performance of
