Re: Support Parallel Query Execution in Executor

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Myron Scott <lister(at)sacadia(dot)com>, Luke Lonergan <llonergan(at)greenplum(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support Parallel Query Execution in Executor
Date: 2006-04-10 09:23:41
Message-ID: 1144661022.3657.15.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Ühel kenal päeval, P, 2006-04-09 kell 18:26, kirjutas Martijn van
Oosterhout:

> The cost of fetching a page from the OS is not really much of an
> overhead,

Have you tested this ?

I remember having a case, where data load usin COPY into a table with
several indexes ran an order of magnitude faster with bigger work-mem.
It was with a computer with enough memory to fit the whole working set
(table + indexes) into OS cache, thus I can't think of any other
overhead except reading the index pages repeatedly from OS cache to
shared mem buffers.

I agree that a real disk read is much slower than OS cache read, but
even an OS cache read is still much slower than no read at all. Sure
it's not nearly as bad on seqscans, but it still takes time.

> so I'd like to know how much benefit these buffer cache hacks
> actually produce.

-------------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2006-04-10 09:44:15 Re: Get explain output of postgresql in Tables
Previous Message Qingqing Zhou 2006-04-10 09:22:13 Re: Support Parallel Query Execution in Executor

Browse pgsql-patches by date

  From Date Subject
Next Message Markus Schiltknecht 2006-04-10 10:02:31 Re: Support Parallel Query Execution in Executor
Previous Message Qingqing Zhou 2006-04-10 09:22:13 Re: Support Parallel Query Execution in Executor