On Mon, 7 Dec 2020 at 14:25, Zhihong Yu <zyu@yugabyte.com> wrote:
>
> > + /* Make a guess at a good size when we're not given a valid size. */
> > + if (size == 0)
> > + size = 1024;
> >
> > Should the default size be logged ?
>
> > I'm not too sure if I know what you mean here. Should it be a power of
> > 2? It is. Or do you mean I shouldn't use a magic number?
>
> Using 1024 seems to be fine. I meant logging the default value of 1024 so that user / dev can have better idea the
actualvalue used (without looking at the code).
Oh, right. In EXPLAIN ANALYZE. Good point. I wonder if that's going
to be interesting enough to show.
> >> Or do you think 98% is not a good number?
>
> Since you have played with Result Cache, I would trust your judgment in choosing the percentage.
> It is fine not to expose this constant until the need arises.
I did some experimentation with different values on a workload that
never gets a cache hit. and just always evicts the oldest entry.
There's only very slight changes in performance between 90%, 98% and
100% with 1MB work_mem.
times in milliseconds measured over 60 seconds on each run.
90% 98% 100%
run1 2318 2339 2344
run2 2339 2333 2309
run3 2357 2339 2346
avg (ms) 2338 2337 2333
Perhaps this is an argument for just removing the logic that has the
soft upper limit and just have it do cache evictions after each
allocation after the cache first fills.
Setup: same tables as [1]
alter table hundredk alter column hundredk set (n_distinct = 10);
analyze hundredk;
alter system set work_mem = '1MB';
select pg_reload_conf();
Query
select count(*) from hundredk hk inner join lookup l on hk.hundredk = l.a;
David
[1] https://www.postgresql.org/message-id/CAApHDvrPcQyQdWERGYWx8J+2DLUNgXu+fOSbQ1UscxrunyXyrQ@mail.gmail.com
