Re: The testing of multi-batch hash joins with skewed data sets patch - Mailing list pgsql-hackers

From Lawrence, Ramon
Subject Re: The testing of multi-batch hash joins with skewed data sets patch
Date
Msg-id 6EEA43D22289484890D119821101B1DF2C1950@exchange20.mercury.ad.ubc.ca
Whole thread Raw
In response to The testing of multi-batch hash joins with skewed data sets patch  ("David Rowley" <dgrowley@gmail.com>)
List pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Tom Lane
> But really there are two different performance regimes here, one where
> the hash data is large enough to spill to disk and one where it isn't.
> Reducing work_mem will cause data to spill into kernel disk cache, but
> if the total problem fits in RAM then very possibly that data won't
ever
> really go to disk.  So I suspect such a test case will act more like
the
> small-data case than the big-data case.  You probably actually need
more
> data than RAM to be sure you're testing the big-data case.

Is there a way to limit the kernel disk cache?  (We are running SUSE
Linux.)

We have been testing hybrid hash join performance and have seen that the
performance varies considerably less than expected even for dramatic
changes in work_mem and the I/Os that appear to be performed.

--
Ramon Lawrence


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: GIN fast insert
Next
From: Bruce Momjian
Date:
Subject: Re: PQinitSSL broken in some use casesf