-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Simon spoke:
> The choice of 100 is because of the way the LIKE estimator is
> configured. Greg is not suggesting he measured it and found 100 to be
> best, he is saying that the LIKE operator is hard-coded at 100 and so
> the stats_target shoul
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
> Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
> there a reason not to make this change? I know I've been lazy and not run
> any absolute figures, but rough tests show that raising it (from 10 to
> 100)
Here is the lastest pgparam patch. It is patched against a fresh
checkout on 2007-12-05.
This release adds support for printf-style param puts/execs. Instead of
having to do a PQputX for each param, you can use a format string and
put multiple params. PQputf(), PQparamExecf() and PQparamSen
[EMAIL PROTECTED] ("Guillaume Smet") writes:
> On Dec 5, 2007 3:26 PM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
>> Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
>> there a reason not to make this change? I know I've been lazy and not run
>> any absolute figures, but r
On Dec 5, 2007 2:44 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Andrew Chernow escribió:
>
> > Also changed PQputint8's prototype. Previously, it was using a void* as
> > the value argument, due to a lack of a portable 64-bit type in libpq. We
> > found an intersting way around this by using m
Andrew Chernow escribió:
> Also changed PQputint8's prototype. Previously, it was using a void* as
> the value argument, due to a lack of a portable 64-bit type in libpq. We
> found an intersting way around this by using macro and variable argument
> tricks.
I didn't read the patch, but varia
Merlin Moncure wrote:
On Dec 5, 2007 2:44 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Andrew Chernow escribió:
Also changed PQputint8's prototype. Previously, it was using a void* as
the value argument, due to a lack of a portable 64-bit type in libpq. We
found an intersting way around this
"Chris Browne" <[EMAIL PROTECTED]> writes:
> - Any columns marked "unique" could keep to having somewhat smaller
>numbers of bins in the histogram because we know that uniqueness
>will keep values dispersed at least somewhat.
I think you're on the wrong track. It's not dispersal that's
Hi,
I ran pgbench with -C option. Here is an output.
% pgbench -C -c 10 -t 100 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 83.209663 (incl
