Variable block size...
I have the variable block size working, but haven't changed
the varchar/char limits to vary with the chosen size. (Also
not positive that I've found everywhere that should be check
the block size).
Without the increased char sizes, there really isn't too much
benefit to changing the disk block size.
I'll do that tomorrow evening though. Damn bean-counters here
at work turn the thermostats back to 55F on the weekends. Not
bad in the day as my cubicle faces east, but come 5:30 and the
joint freezes up again.
Also grep'd around the src for increasing the packet size to
32768 (or _32769_ for _libpq_).
Why oh why does libpq have a max size of 8193? Is the extra 1
a hack? Drove me nuts trying to figure out where the max packet
size begin set at 8k...finally grep'd for 819 and there it was.
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)
Time to split, my hands are almost too cold to type any more...
darrenk
On Sun, 1 Feb 1998, Darren King wrote:
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)
What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...
Well, it's OK to leave _one_ feature for v6.4. Bruce is probably tired of typing
the feature list :)
Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
go in and not affect anything if we run using the current block size.
- Tom
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...Well, it's OK to leave _one_ feature for v6.4. Bruce is probably tired of typing
the feature list :)Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
go in and not affect anything if we run using the current block size.
Great chance of having it by Friday if not sooner. I'll get on it tonite.
Wasn't sure where the line in the sand was for "adding features" vs "fixing bugs."
Thanks,
Darren
Import Notes
Resolved by subject fallback
On Mon, 2 Feb 1998, Darren King wrote:
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...Well, it's OK to leave _one_ feature for v6.4. Bruce is probably tired of typing
the feature list :)Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
go in and not affect anything if we run using the current block size.Great chance of having it by Friday if not sooner. I'll get on it tonite.
Wasn't sure where the line in the sand was for "adding features" vs
"fixing bugs."
The only *fixed* date is march 1st...certain developers have a
little leeway as far as the beta release is concerned...leeway tending to
depend on how quickly bugs they generate get fixed...anyway, fixed sized
block sizes are a bug, aren't they? *grin*
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...Well, it's OK to leave _one_ feature for v6.4. Bruce is probably tired of typing
the feature list :)
Already on the HISTORY, because some of the changes were already made:
Allow installation data block size and max tuple size configuration(Darren)
--
Bruce Momjian
maillist@candle.pha.pa.us
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...Well, it's OK to leave _one_ feature for v6.4. Bruce is probably tired of typing
the feature list :)Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
go in and not affect anything if we run using the current block size.Great chance of having it by Friday if not sooner. I'll get on it tonite.
Wasn't sure where the line in the sand was for "adding features" vs "fixing bugs."
I think Marc is getting softer on this issue. [Ducks head]
--
Bruce Momjian
maillist@candle.pha.pa.us
On Mon, 2 Feb 1998, Bruce Momjian wrote:
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...Well, it's OK to leave _one_ feature for v6.4. Bruce is probably
tired of typing the feature list :)Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
go in and not affect anything if we run using the current block size.
Great chance of having it by Friday if not sooner. I'll get on it tonite.
Wasn't sure where the line in the sand was for "adding features" vs "fixing bugs."
I think Marc is getting softer on this issue. [Ducks head]
Moi? Never...some ppl have shown over time a...dedication towards
fixing any bugs they introduce in a *very* timely manner *grin* A little
leeway, as appropriate, tends to reap large rewards for all
parties...specially if we can help improve disk space usage by providing
the ability to tailor disk block size used :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Looks like this variable size stuff will be the first new feature
for 6.4 then, eh? :)What is the chance of having this ready by Friday? Still would
give us 3weeks of debugging...Well, it's OK to leave _one_ feature for v6.4. Bruce is probably
tired of typing the feature list :)Also, we still have a few loose ends for v6.3. But, I'll bet Darren's stuff can
go in and not affect anything if we run using the current block size.Great chance of having it by Friday if not sooner. I'll get on it tonite.
Wasn't sure where the line in the sand was for "adding features" vs "fixing bugs."
I think Marc is getting softer on this issue. [Ducks head]
Moi? Never...some ppl have shown over time a...dedication towards
fixing any bugs they introduce in a *very* timely manner *grin* A little
leeway, as appropriate, tends to reap large rewards for all
parties...specially if we can help improve disk space usage by providing
the ability to tailor disk block size used :)
The variable block size stuff won't be done by tonite. Something I've done in
the tape sorting routines is causing a core dump during the constraints regression
test and I haven't been able to track it down the last two evenings.
Sorry about that folks. I'm going to keep on it, but I wouldn't feel too
comfortable putting in the beta any later than now.
darrenk
Import Notes
Resolved by subject fallback