On Mon, Nov 5, 2012 at 3:58 PM, Marko Kreen wrote:
> On Tue, Nov 6, 2012 at 1:31 AM, Jeff Janes wrote:
>> On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen wrote:
>>> On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes wrote:
On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries
(like "s
On Tue, Nov 6, 2012 at 1:31 AM, Jeff Janes wrote:
> On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen wrote:
>> On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes wrote:
>>> On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries
>>> (like "select 1;" or "set timezone...") against 2 instances of
>>>
On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen wrote:
> On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes wrote:
>> On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries
>> (like "select 1;" or "set timezone...") against 2 instances of
>> pgbouncer, I get nearly twice the throughput as if I use
On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes wrote:
> On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries
> (like "select 1;" or "set timezone...") against 2 instances of
> pgbouncer, I get nearly twice the throughput as if I use only one
> instance.
>
> A rather odd workload, maybe, b
On Sat, Nov 3, 2012 at 6:53 PM, Jeff Janes wrote:
> On Wed, Oct 31, 2012 at 11:39 AM, Merlin Moncure wrote:
>> On Tue, Oct 30, 2012 at 4:58 PM, Jeff Janes wrote:
>>> On Mon, Oct 29, 2012 at 5:11 PM, Catalin Iacob
>>> wrote:
>>>
pgbouncer 1.4.2 installed from Ubuntu's packages on the same
On Sun, Nov 4, 2012 at 2:32 PM, Claudio Freire wrote:
>> Well, what "partition" actually means is "only bother to try constraint
>> exclusion proofs on appendrel members". UNION ALL trees will get
>> flattened into appendrels in some cases. In a quick look at the code,
>> it seems like in recent
On Mon, Nov 5, 2012 at 2:40 PM, Claudio Freire wrote:
> On Mon, Nov 5, 2012 at 2:09 PM, Jeff Janes wrote:
In my experience when doing sorts in isolation, having more work_mem
is a bad thing, unless it enables you to remove a layer of
tape-merging. I always blamed it on the L1/L2 e
On Mon, Nov 5, 2012 at 2:09 PM, Jeff Janes wrote:
>>> In my experience when doing sorts in isolation, having more work_mem
>>> is a bad thing, unless it enables you to remove a layer of
>>> tape-merging. I always blamed it on the L1/L2 etc. levels of caching.
>>
>> Blame it on quicksort, which is
On Tue, Oct 30, 2012 at 6:08 AM, Tatsuo Ishii wrote:
>> i have sql file (it's size are 1GB )
>> when i execute it then the String is 987098801 bytr too long for encoding
>> conversion error occured .
>> pls give me solution about
>
> You hit the upper limit of internal memory allocation limit in
On Mon, Nov 5, 2012 at 8:48 AM, Claudio Freire wrote:
> On Mon, Nov 5, 2012 at 1:44 PM, Jeff Janes wrote:
>>> Well, I'm pretty sure that having more work_mem is a good thing (tm)
>>> normally ;-)
>>
>> In my experience when doing sorts in isolation, having more work_mem
>> is a bad thing, unless
On Mon, Nov 5, 2012 at 1:44 PM, Jeff Janes wrote:
>> Well, I'm pretty sure that having more work_mem is a good thing (tm)
>> normally ;-)
>
> In my experience when doing sorts in isolation, having more work_mem
> is a bad thing, unless it enables you to remove a layer of
> tape-merging. I always
On Sat, Nov 3, 2012 at 10:09 AM, Gunnar "Nick" Bluth
wrote:
> Well, I'm pretty sure that having more work_mem is a good thing (tm)
> normally ;-)
In my experience when doing sorts in isolation, having more work_mem
is a bad thing, unless it enables you to remove a layer of
tape-merging. I alway
On Sun, Nov 4, 2012 at 7:23 PM, Dong Ye wrote:
>> You are using prepared statements, this makes me think that this
>> regression might be due to support for parameter specific plans for
>> prepared statements. [1] Can you run the test on both versions without
>> prepared statements and see if the
Title: Documento sin título
Hello,
I have this table definition:
CREATE TABLE ism_floatvalues
(
id_signal bigint NOT NULL, -- Indica la señal a la que pertenece
este valor. Clave foránea que referencia al campo id_signal de la
tabla ism_signal.
time_stam
Pedro Jiménez Pérez wrote:
> Sent: Friday, November 02, 2012 1:14 PM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] help with too slow query
>
> Hello,
> I have this table definition:
> CREATE TABLE ism_floatvalues
> (
> id_signal bigint NOT NULL, -- Indica la señal a la que perte
On 1 November 2012 18:25, Gunnar "Nick" Bluth wrote:
> Am 01.11.2012 21:40, schrieb Marcos Ortiz:
>
> Regards, Petr.
> Tuning PostgreSQL is not just change the postgresql.conf, it includes more
> things like:
> - the filesystem that you are using
> - the kernel version that you using (particularl
> You are using prepared statements, this makes me think that this
> regression might be due to support for parameter specific plans for
> prepared statements. [1] Can you run the test on both versions without
> prepared statements and see if the regressions remains.
Without prepare statement, we
2012/11/2 Pedro Jiménez Pérez
> I have this table definition:
>
1) Could you kindly include also information bout ism_signal and
ism_installation
tables?
2) Please, follow this guide to provide more input:
http://wiki.postgresql.org/wiki/Slow_Query_Questions
--
Victor Y. Yegorov
On 3 November 2012 05:31, Gunnar "Nick" Bluth wrote:
> Am 02.11.2012 17:12, schrieb Petr Praus:
>
> Your CPUs are indeed pretty oldschool. FSB based, IIRC, not NUMA. A
> process migration would be even more expensive there.
>
>Might be worth to
>> - manually pin (with taskset) the session you
On 3 November 2012 12:09, Gunnar "Nick" Bluth wrote:
> Am 03.11.2012 16:20, schrieb Petr Praus:
>
>
>Your CPUs are indeed pretty oldschool. FSB based, IIRC, not NUMA. A
>> process migration would be even more expensive there.
>>
>>
> Ok, I've actually looked these up now... at the time these
- I'm using ext4
- Kernel: Linux 2.6.32-279.9.1.el6.x86_64 #1 SMP Fri Aug 31 09:04:24 EDT
2012 x86_64 x86_64 x86_64 GNU/Linux
- I haven't tuned kernel in any way except setting kernel.shmmax and
kernel.shmall to:
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
- We are using 15k drives (magn
I'm running a server with lots of counts and calculations.
currently its ubuntu server is freebsd faster?
also this is a i386 machine.
or linux and bsd is about the same.
this is not to be an argument just looking. Current benchmarks to compare
thanks
I did run each query several times, the results I posted are for ~10th run
of the query.
The zone reclaim mode is 0.
On 2 November 2012 00:39, Scott Marlowe wrote:
> Two possibilities:
>
> caching. make sure to run each query several times in a row.
>
> zone reclaim mode. If this has gotten t
23 matches
Mail list logo
