Re: Patch 0.2 for Re: [HACKERS] Caching number of blocks in relation to avoi lseek.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Denis Perchine <dyp(at)perchine(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch 0.2 for Re: [HACKERS] Caching number of blocks in relation to avoi lseek.
Date: 2000-06-14 03:19:19
Message-ID: 200006140319.XAA20608@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Yoo, hoo. No one complained about this patch, so in it goes. I bet
this will be a real speedup on some platforms. I know some OS's don't
do fseek() as fast as we would like.

Thanks.

> > If read or write fails. Position will left the same. This situation is already tracked
> > in File routines, but a little bit incorrectly.
>
> After small survey in Linux kernel code, I am not sure about it.
> New patch set pos to unknown in the case of read/write fails. And do
> lseek again.
>
> > 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(at)perchine(dot)com
> HomePage: http://www.perchine.com/dyp/
> FidoNet: 2:5000/120.5
> ----------------------------------

[ Attachment, skipping... ]

Index: fd.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/file/fd.c,v
retrieving revision 1.59
diff -c -b -w -r1.59 fd.c
*** fd.c 2000/06/02 15:57:24 1.59
--- fd.c 2000/06/13 08:34:55
***************
*** 95,100 ****
--- 95,102 ----

#define FileIsNotOpen(file) (VfdCache[file].fd == VFD_CLOSED)

+ #define FileUnknownPos (-1)
+
typedef struct vfd
{
signed short fd; /* current FD, or VFD_CLOSED if none */
***************
*** 790,795 ****
--- 792,799 ----
returnCode = read(VfdCache[file].fd, buffer, amount);
if (returnCode > 0)
VfdCache[file].seekPos += returnCode;
+ else
+ VfdCache[file].seekPos = FileUnknownPos;

return returnCode;
}
***************
*** 806,816 ****

FileAccess(file);
returnCode = write(VfdCache[file].fd, buffer, amount);
! if (returnCode > 0)
VfdCache[file].seekPos += returnCode;
-
/* mark the file as needing fsync */
VfdCache[file].fdstate |= FD_DIRTY;

return returnCode;
}
--- 810,821 ----

FileAccess(file);
returnCode = write(VfdCache[file].fd, buffer, amount);
! if (returnCode > 0) {
VfdCache[file].seekPos += returnCode;
/* mark the file as needing fsync */
VfdCache[file].fdstate |= FD_DIRTY;
+ } else
+ VfdCache[file].seekPos = FileUnknownPos;

return returnCode;
}
***************
*** 840,849 ****
default:
elog(ERROR, "FileSeek: invalid whence: %d", whence);
break;
- }
}
! else
VfdCache[file].seekPos = lseek(VfdCache[file].fd, offset, whence);
return VfdCache[file].seekPos;
}

--- 845,870 ----
default:
elog(ERROR, "FileSeek: invalid whence: %d", whence);
break;
}
! } else
! switch (whence) {
! case SEEK_SET:
! if (offset < 0)
! elog(ERROR, "FileSeek: invalid offset: %ld", offset);
! if (VfdCache[file].seekPos != offset)
! VfdCache[file].seekPos = lseek(VfdCache[file].fd, offset, whence);
! break;
! case SEEK_CUR:
! if ((offset != 0) || (VfdCache[file].seekPos == FileUnknownPos));
VfdCache[file].seekPos = lseek(VfdCache[file].fd, offset, whence);
+ break;
+ case SEEK_END:
+ VfdCache[file].seekPos = lseek(VfdCache[file].fd, offset, whence);
+ break;
+ default:
+ elog(ERROR, "FileSeek: invalid whence: %d", whence);
+ break;
+ }
return VfdCache[file].seekPos;
}

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Wilson 2000-06-14 03:25:18 Modifying NOT NULL Constraint
Previous Message Tom Lane 2000-06-14 02:59:26 Re: 7.0.2 cuts off attribute name

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2000-06-14 04:52:38 Re: Small patch for memory leak in src/backend/catalog/pg_proc.c
Previous Message Bruce Momjian 2000-06-14 02:56:17 Re: Big 7.1 open items