"Huang, Suya" writes:
> For the first point you made, you're right. The real execution time varies a
> lot from the explain analyze, the query on parent table are just as fast as
> it is on the child table. is this a bug of explain analyze command? While we
> reading the execution plan, shall
An update: following the recommendations on this list, I ran a number of
experiments:
- I ran with all foreign keys deleted. There was a 4% drop in the rate of
deadlocks/transaction, which went from 0.32 per transaction to 0.31. So we
still have pretty much the same failure rate. One interestin
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, August 21, 2014 12:13 AM
To: Huang, Suya
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] query on parent partition table has bad performance
"Huang, Suya" writes:
> I have a question about partition
> On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
>> On a read-write test, it's 10% faster with HT off as well.
>>
>> Further, from their production machine we've seen that having HT on
>> causes the machine to slow down by 5X whenever you get more than 40
>> cores (as in 100% of real
On Wed, Aug 20, 2014 at 12:13:50PM -0700, Josh Berkus wrote:
> On a read-write test, it's 10% faster with HT off as well.
>
> Further, from their production machine we've seen that having HT on
> causes the machine to slow down by 5X whenever you get more than 40
> cores (as in 100% of real cores
On Wed, Aug 20, 2014 at 1:36 PM, Shaun Thomas wrote:
> That's so strange. Back when I did my Nehalem tests, we got a very strong
> 30%+ increase by enabling HT. We only got a hit when we turned off turbo, or
> forgot to disable power saving features.
In my experience, it is crucially important to
On 21/08/14 07:13, Josh Berkus wrote:
Mark, all:
So, this is pretty damming:
Read-only test with HT ON:
[pgtest@db ~]$ pgbench -c 20 -j 4 -T 600 -S bench
starting vacuum...end.
transaction type: SELECT only
scaling factor: 30
query mode: simple
number of clients: 20
number of threads: 4
durati
Kevin Grittner wrote:
> Dave Owens wrote:
>
>> I now have 8 hours worth of snapshots from pg_stat_activity and
>> pg_locks (16 snapshots from each table/view). I have turned off
>> collection at this point, but I am still able to query pg_locks
>
> Could you take the earliest one after activity
On 08/20/2014 02:13 PM, Josh Berkus wrote:
So we're definitely back to "If you're using PostgreSQL, turn off
Hyperthreading".
That's so strange. Back when I did my Nehalem tests, we got a very
strong 30%+ increase by enabling HT. We only got a hit when we turned
off turbo, or forgot to disab
Mark, all:
So, this is pretty damming:
Read-only test with HT ON:
[pgtest@db ~]$ pgbench -c 20 -j 4 -T 600 -S bench
starting vacuum...end.
transaction type: SELECT only
scaling factor: 30
query mode: simple
number of clients: 20
number of threads: 4
duration: 600 s
number of transactions actuall
Dave Owens wrote:
> I now have 8 hours worth of snapshots from pg_stat_activity and
> pg_locks (16 snapshots from each table/view). I have turned off
> collection at this point, but I am still able to query pg_locks
Could you take the earliest one after activity started, and the
latest one befo
I now have 8 hours worth of snapshots from pg_stat_activity and
pg_locks (16 snapshots from each table/view). I have turned off
collection at this point, but I am still able to query pg_locks:
# SELECT mode, count(mode) AS count FROM pg_locks GROUP BY mode ORDER BY mode;
mode | coun
"Huang, Suya" writes:
> I have a question about partition table query performance in postgresql, it's
> an old version 8.3.21, I know it's already out of support. so any words about
> the reason for the behavior would be very much appreciated.
> I have a partition table which name is test_rank_
Huang, Suya wrote
> Hi,
>
> I have a question about partition table query performance in postgresql,
> it's an old version 8.3.21, I know it's already out of support. so any
> words about the reason for the behavior would be very much appreciated.
>
> I have a partition table which name is test_r
Hi,
I have a question about partition table query performance in postgresql, it's
an old version 8.3.21, I know it's already out of support. so any words about
the reason for the behavior would be very much appreciated.
I have a partition table which name is test_rank_2014_monthly and it has 7
15 matches
Mail list logo
