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
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 |
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 |