On Sun, 17 Jul 2005, Tom Lane wrote:
> The short answer is that you should install flex 2.5.4, or else forget
> about testing the 7.2 branch. I don't think anyone will be very
> interested in making 7.2 work with flex 2.5.31.
>
Actually there are problems in the 7.3 branch as well in the cube
Hiroki Kataoka <[EMAIL PROTECTED]> writes:
> This small patch improves the performance of INSERT and UPDATE. By my
> machine, these changes raised the performance about 5%~10% in pgbench.
BTW, in profiling the backend I've never seen PageAddItem take more than
about 1% of the runtime, and in pgbe
Hiroki Kataoka <[EMAIL PROTECTED]> writes:
> This small patch improves the performance of INSERT and UPDATE. By my
> machine, these changes raised the performance about 5%~10% in pgbench.
Wouldn't it be a lot less invasive to search down from the end, instead
of changing the page header format?
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ISTM the point of the delay parameters
>> for autovac is to put a lid on its impact on interactive response. Seen
>> in that light, you do not care exactly which table it's hitting at the
>> moment.
> Unless the table in question takes a
Hi all,
This small patch improves the performance of INSERT and UPDATE. By my
machine, these changes raised the performance about 5%~10% in pgbench.
Please take a benchmark in a reliable environment. Since I may forget
some required changes, I specify that this patch is experimental. But
note
"Pete St. Onge" <[EMAIL PROTECTED]> writes:
> Perhaps this will help in the diagnosis of why REL7_2_STABLE fails on
> arbor (aka caribou). Please let me know if there is anything I can try
> on this side, or if there is any other info you could use.
> [EMAIL PROTECTED]:~$ flex -V
> flex 2.5.31
Ah
I spent a little time today cleaning up easily-fixed problems that are
causing buildfarm failures in various back branches. Hopefully that
will result in a few more "green" entries over the new few days. While
I was looking, I noticed several machines that seem to be failing
because of local issu
Bruce Momjian wrote:
>
> I don't think our problem is partial writes of WAL, which we already
> check, but heap/index page writes, which we currently do not check for
> partial writes.
Hmm...I've read through the thread again and thought about the problem
further, and now think I understand what
Tom Lane wrote:
ISTM the point of the delay parameters
for autovac is to put a lid on its impact on interactive response. Seen
in that light, you do not care exactly which table it's hitting at the
moment.
Unless the table in question takes a big lock when it's VACUUMed
like tables with GiST
Kris Jurka <[EMAIL PROTECTED]> writes:
> consider what would happen if the shared library didn't exist at all and
> only a static version were available. Until this recent batch of pgcrypto
> changes everything built fine.
Well, the right answer to that really is that pgcrypto ought not try to
On Sat, 16 Jul 2005, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
>
> > The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib
> > while libz.so is in /usr/lib.
>
> Well, that is a flat-out configuration error on the local sysadmin's
> part. I can't think of any
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Sat, 16 Jul 2005, Tom Lane wrote:
>> This sure seems like a crude band-aid rather than an actual solution.
>> The bug as I see it is that gcc is choosing to link libz.a rather than
>> libz.so --- why is that happening?
> The link line says -L/usr/local/l
On Sat, 16 Jul 2005, Tom Lane wrote:
> Marko Kreen writes:
> > I googled a bit and found two suggestions:
> >
> > 1. http://curl.haxx.se/mail/lib-2002-01/0092.html
> > (Use -mimpure-text on linking line)
> >
> This sure seems like a crude band-aid rather than an actual solution.
> The bug as
On Sat, 16 Jul 2005, Christopher Kings-Lynne wrote:
> > This has been covered before, but to reiterate: why would you need this?
> > Any application worth its salt should be tracking which statements it
> > has already prepared (after all, they cannot span connections). Seems
> > a waste of reso
Marko Kreen writes:
> On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
>>> Well the buildfarm machine kudu is actually the same machine just building
>>> with the Sun compiler and it works fine. It links all of libz.a into
>>> libpgcrypto.so while gcc refuses to.
>
> I googled a bit
On Sat, 2005-07-16 at 08:17 -0400, Bruce Momjian wrote:
> Rod Taylor wrote:
> > This may sound silly, but any chance we could change autovacuum_* GUC
> > variables to be vacuum_auto_* instead?
> >
> > This way when you issue a SHOW ALL, all of the vacuum related parameters
> > would be in the same
Rod Taylor wrote:
> This may sound silly, but any chance we could change autovacuum_* GUC
> variables to be vacuum_auto_* instead?
>
> This way when you issue a SHOW ALL, all of the vacuum related parameters
> would be in the same place.
Well, the autovacuum items control just autovacuum, while v
I don't think our problem is partial writes of WAL, which we already
check, but heap/index page writes, which we currently do not check for
partial writes.
---
Kevin Brown wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PRO
On Fri, Jul 15, 2005 at 08:06:15PM -0500, Kris Jurka wrote:
> On Fri, 15 Jul 2005, Marko Kreen wrote:
>
> > [buildfarm machine dragonfly]
> >
> > On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
> > > Well the buildfarm machine kudu is actually the same machine just
> > > building
>
Am Freitag, 15. Juli 2005 14:19 schrieb Greg Sabino Mullane:
> > The use case is when you want to prepare a query, but only if it's not
> > already prepared on that connection.
>
> This has been covered before, but to reiterate: why would you need this?
> Any application worth its salt should be tr
20 matches
Mail list logo
