Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
> <kevin.gritt...@wicourts.gov> wrote:
>> I'm finding that even the ones that had a plan time in the range of
>> 260 ms go down to 15 ms to 85 ms once the statistics are cached.
> I had some performance results back when we were last looking at
> default_statistics_target that indicated that the time to repeatedly
> decompress a toasted statistics array contributed significantly to the
> total planning time, but my suggestion to disable compression for
> pg_statistic was summarily poo-poohed for reasons that still aren't
> quite clear to me.
Well, smaller is better. Kevin's example demonstrates that it's good
to have the stats sucked into cache. If they were uncompressed then
less of them would fit in however much cache space you have, and
whatever CPU savings you get would be lost to more I/O to read in
stats entries.
Of course, this all depends on total database size vs total RAM,
but that's how I'd interpret the observation. PG is still mostly
optimized for databases bigger than RAM, so this decision still
makes sense.
(I think you could try marking the columns of pg_statistic as "don't
compress" if you have a DB you want to optimize for all-in-memory
behavior.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
