Hello again, I am back with new experiments.
First of all, I have a concrete set of steps that replicate the
slowness of the hash join that I described. If you have a system with
spinning disks lying around, I would appreciate if you can verify the
scenario. Can you also replicate it in different
On Sat, 14 Jan 2023, Tom Lane wrote:
Dimitrios Apostolou writes:
Please correct me if I'm wrong, as I'm a newcomer to PostgreSQL, but here
is how I understand things according to posts I've read, and classical
algorithms:
+ The Hash Join is fastest when one side fits in work_mem. Then on on
Dimitrios Apostolou writes:
> Please correct me if I'm wrong, as I'm a newcomer to PostgreSQL, but here
> is how I understand things according to posts I've read, and classical
> algorithms:
> + The Hash Join is fastest when one side fits in work_mem. Then on one
>hand you have a hash table l
On Fri, 13 Jan 2023, David Rowley wrote:
I'd expect reducing random_page_cost to make the Mege Join cheaper as
that's where the Index Scan is. I'm not quite sure where you think the
random I/O is coming from in a batched hash join.
Thanks for the feedback, indeed you are right! Decreasing ra
On Fri, 13 Jan 2023 at 07:33, Dimitrios Apostolou wrote:
>
> I have a very simple NATURAL JOIN that does not fit in the work_mem. Why
> does the query planner prefer a hash join that needs 361s, while with a
> sort operation and a merge join it takes only 13s?
It's a simple matter of that the Ha
Hello list,
I have a very simple NATURAL JOIN that does not fit in the work_mem. Why
does the query planner prefer a hash join that needs 361s, while with a
sort operation and a merge join it takes only 13s?
The server is an old Mac Mini with hard disk drive and only 4GB RAM.
Postgres version i
