| From: | Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Julius Stroffek <Julius(dot)Stroffek(at)sun(dot)com>, pgsql-hackers(at)postgresql(dot)org, Dano Vojtek <danielkov(at)gmail(dot)com> |
| Subject: | Re: Multi CPU Queries - Feedback and/or suggestions wanted! |
| Date: | 2008-10-30 09:47:30 |
| Message-ID: | 490982B2.7000708@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Greg Stark wrote:
>
>> I couldn't get async I/O to work on Linux. That is it "worked" but
>> performed the same as reading one block at a time. On solaris the
>> situation is reversed.
>>
>> In what way is fadvise a kludge?
>>
>
> I think he is saying AIO gives us more flexibility, but I am unsure we
> need it.
>
absolutely.
posix_fadvise is easy to implement and i would assume that it takes away
a lot of "guessing" on the OS internals side.
the database usually knows that it is gonna read a lot of data in a
certain way and it cannot be a bad idea to give the kernel a hint here.
especially synchronized seq scans and so on are real winners here as you
stop confusing the kernel with XX concurrent readers on the same file.
this can also be an issue with some controller firmwares and so on.
many thanks,
hans
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2008-10-30 09:57:58 | Re: Updating FSM on recovery |
| Previous Message | Martin Pihlak | 2008-10-30 08:41:28 | Re: SQL/MED compatible connection manager |