| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel Seq Scan vs kernel read ahead |
| Date: | 2020-07-22 03:56:58 |
| Message-ID: | CAA4eK1+0M9WP-v3S=WsCnkazmGSZseBGU-HzNph88Atepx+0zg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 22, 2020 at 5:25 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> I understand that Amit wrote:
>
> On Fri, 17 Jul 2020 at 21:18, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > I think recreating the database and restarting the server after each
> > run might help in getting consistent results. Also, you might want to
> > take median of three runs.
>
> Please also remember, if you're recreating the database after having
> restarted the machine that creating the table will likely end up
> caching some of the pages either in shared buffers or the Kernel's
> cache.
>
Yeah, that is true but every time before the test the same amount of
data should be present in shared buffers (or OS cache) if any which
will help in getting consistent results. However, it is fine to
reboot the machine as well if that is a convenient way.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2020-07-22 04:32:41 | Re: Parallel Seq Scan vs kernel read ahead |
| Previous Message | Amit Kapila | 2020-07-22 03:48:32 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |