On 4 May 2012 17:39, Tom Lane wrote:
> I get a reasonable-looking plan when I try to duplicate this issue in
> 9.1 branch tip. I think the reason you're not getting the right
> behavior is that you are missing this as-yet-unreleased patch:
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=co
Richard Jones writes:
> I'm seeing poor query performance using partitioned tables with check
> constraints, seems like the plan is much worse than when querying the
> individual partitions manually.
> select version(); --> PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu,
> compiled by gcc (Debian 4
On Fri, May 4, 2012 at 8:07 AM, Jan Nielsen wrote:
> Starting to get some quantitative data now. Here is the results from the
> pgbench scaling:
>
> pgbench -t 2000 -c 32 -S pgbench
A single thread of pgbench is probably not enough to saturate 32
sessions. What if you try -j 16 or -j 32?
Also
Jan Nielsen wrote:
> The range 2048-8192 is an area to study in more detail, obviously.
> Feedback welcome.
I don't see what's to study there, really. Performance drops off
when database size grows from 30GB to 60GB on a system with 48GB
RAM. And even more when you double database size again.
Starting to get some quantitative data now. Here is the results from the
pgbench scaling:
pgbench -t 2000 -c 32 -S pgbench
for scales of 2^n where n=0..14 for scale, DB size in MB, and transactions
per second:
Scale DB Size TPS
---
1 21 65618
2 36 66060
Hi,
I'm seeing poor query performance using partitioned tables with check
constraints, seems like the plan is much worse than when querying the
individual partitions manually.
select version(); --> PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu,
compiled by gcc (Debian 4.4.5-8) 4.4.5, 64-bit
uname
Hi Tom, Kevin,
>> I have a query which is running slowly, and the query plan shows an
> unexpected sequence scan where I'd have expected the planner to use an
> index. Setting enable_seqscan=off causes the planner to use the index as
> expected.
>
> That hashjoin plan doesn't look at all unreason
Dan Fairs writes:
> I have a query which is running slowly, and the query plan shows an
unexpected sequence scan where I'd have expected the planner to use an
index. Setting enable_seqscan=off causes the planner to use the index as
expected.
That hashjoin plan doesn't look at all unreasonable to
Dan Fairs wrote:
> I have a query which is running slowly, and the query plan shows
> an unexpected sequence scan where I'd have expected the planner to
> use an index.
Looking at the actual row counts compared to run time, it appears
that the active portion of your data set is heavily cached
Hi,
I'm fairly new to PostgreSQL query tuning, so please forgive me if I've
overlooked something obvious.
I have a query which is running slowly, and the query plan shows an unexpected
sequence scan where I'd have expected the planner to use an index. Setting
enable_seqscan=off causes the plan
Hi again,
>> That doesn't sound like a tremendously good idea to me.
> Could you elaborate on the downsides of this approach a bit?
Any other thoughts about the pro/cons replacing IN(subquery) with
=ANY(ARRAY(subquery))?
Are there patological cases, except when the subquery returns a huge
amount
On Thu, May 3, 2012 at 12:07 PM, Eyal Wilde wrote:
> guess what:
>
> after reducing bo (blocks out) to ~10% by using a ramdisk (improving overall
> performance by ~15-20%), i now managed to reduced it to ~3% by removing
> the "analyze temp-table" statements.
> it also :
> reduced b (Process w
On 03/05/2012 16:46, Craig James wrote:
On Thu, May 3, 2012 at 6:42 AM, Jan Nielsen wrote:
Hi John,
On Thu, May 3, 2012 at 12:54 AM, John Lister
wrote:
I was wondering if it would be better to put the xlog on the same disk as
the OS? Apart from the occasional log writes I'd have thought most
guess what:
after reducing bo (blocks out) to ~10% by using a ramdisk (improving
overall performance by ~15-20%), i now managed to reduced it to ~3% by
removing the "analyze temp-table" statements.
it also :
reduced b (Process which are waiting for I/O) to zero
reduced wa (percentage of time
> That sounds interesting. How do you identify a page flush storm?
Maybe I used the wrong terminology. What effectively happens if you reach the
amount of memory specified in dirty_ratio, is that the system goes from
asynchronous disk access, to synchronous disk access, and starts flushing that
On 05/03/2012 02:28 AM, Robert Klemme wrote:
Maybe this also has some additional input:
http://www.fccps.cz/download/adv/frr/hdd/hdd.html
Be careful with that link. His recommendations for dirty_ratio and
dirty_background_ratio would be *very bad* in a database setting. Note
this from the ac
Martin Grotzke wrote:
>> You could try different kernel I/O elevators and see if that improves
>> something.
>>
>> I have made good experiences with elevator=deadline and
elevator=noop.
> Ok, great info.
>
> I'm not sure at which device to look honestly to check the current
> configuration.
>
>
17 matches
Mail list logo
