Patch for Re: [HACKERS] Caching number of blocks in relation to avoi lseek.
От | Denis Perchine |
---|---|
Тема | Patch for Re: [HACKERS] Caching number of blocks in relation to avoi lseek. |
Дата | |
Msg-id | 00061315252504.00525@dyp обсуждение исходный текст |
Ответы |
Patch 0.2 for Re: [HACKERS] Caching number of blocks in relation to avoi lseek.
|
Список | pgsql-patches |
> Oh. Hmm. Not sure if it's really worth the trouble, but you could try > having fd.c keep track of the current seek position of VFDs when they > are open as well as when they are closed, and optimize away the lseek > call in FileSeek if the position is already right. You'd have to think > carefully about what to do if a read or write fails, however --- where > has the kernel left its seek position in that case? Possibly this could > be dealt with by setting the internal position to "unknown" anytime > we're not perfectly sure where the kernel is. If read or write fails. Position will left the same. This situation is already tracked in File routines, but a little bit incorrectly. Here is the full patch for this. This patch reduce amount of lseek call ten times for update statement and twenty times for select statement. I tested joined update and count(*) select for table with rows > 170000 and 10 indices. I think this is worse of trying. Before lseek calls account for more than 5% of time. Now they are 0.89 and 0.15 respectevly. Due to only one file modification patch should be applied in src/backedn/storage/file/ dir. -- Sincerely Yours, Denis Perchine ---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ----------------------------------
Вложения
В списке pgsql-patches по дате отправления: