=?iso-8859-1?Q?V=E1clav_Ovs=EDk?= writes:
> I think the execution plan is poor. Better would be to filter table
> attachments
> at first and then join the rest. The reason is a bad estimate on number of
> rows
> returned from table tickets (85 estimated -> 25410 in the reality).
> ...
> The prob
Zito,
Using psql log in as the database owner and run "analyze verbose". Happiness
will ensue.
Also, when requesting help with a query its important to state the database
version ("select version();") and what, if any, configuration changes you have
made in postgresql.conf. Listing ony the
Hi,
I have done migration of the Request Tracker 3.8.9
(http://requesttracker.wikia.com/wiki/HomePage) from Mysql to
PostgreSQL in testing environment.
The RT schema used can be viewed at
https://github.com/bestpractical/rt/blob/3.8-trunk/etc/schema.Pg.
I have added full text search on table Attach
Dne 12.4.2011 23:19, Ogden napsal(a):
>
> On Apr 12, 2011, at 4:09 PM, Tomas Vondra wrote:
>
>> Dne 12.4.2011 20:28, Ogden napsal(a):
>>>
>>> On Apr 12, 2011, at 1:16 PM, Tomas Vondra wrote:
>>>
Dne 12.4.2011 19:23, Ogden napsal(a):
>
> On Apr 12, 2011, at 12:18 PM, Andreas Kretschme
On Apr 12, 2011, at 4:09 PM, Tomas Vondra wrote:
> Dne 12.4.2011 20:28, Ogden napsal(a):
>>
>> On Apr 12, 2011, at 1:16 PM, Tomas Vondra wrote:
>>
>>> Dne 12.4.2011 19:23, Ogden napsal(a):
On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
> Ogden wrote:
>
>>
Dne 12.4.2011 20:28, Ogden napsal(a):
>
> On Apr 12, 2011, at 1:16 PM, Tomas Vondra wrote:
>
>> Dne 12.4.2011 19:23, Ogden napsal(a):
>>>
>>> On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
>>>
Ogden wrote:
> I have been wrestling with the configuration of the dedicated Pos
When purchasing the intel 7500 series, please make sure to check the hemisphere
mode of your memory configuration. There is a HUGE difference in the memory
configuration around 50% speed if you don't populate all the memory slots on
the controllers properly.
https://globalsp.ts.fujitsu.com/dms
On Apr 12, 2011, at 1:16 PM, Tomas Vondra wrote:
> Dne 12.4.2011 19:23, Ogden napsal(a):
>>
>> On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
>>
>>> Ogden wrote:
>>>
I have been wrestling with the configuration of the dedicated Postges 9.0.3
server at work and granted, ther
Dne 12.4.2011 19:23, Ogden napsal(a):
>
> On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
>
>> Ogden wrote:
>>
>>> I have been wrestling with the configuration of the dedicated Postges 9.0.3
>>> server at work and granted, there's more activity on the production server,
>>> but
>>> the
On Apr 12, 2011, at 12:18 PM, Andreas Kretschmer wrote:
> Ogden wrote:
>
>> I have been wrestling with the configuration of the dedicated Postges 9.0.3
>> server at work and granted, there's more activity on the production server,
>> but
>> the same queries take twice as long on the beefier se
Ogden wrote:
> I have been wrestling with the configuration of the dedicated Postges 9.0.3
> server at work and granted, there's more activity on the production server,
> but
> the same queries take twice as long on the beefier server than my mac at home.
> I have pasted what I have changed in p
On Tue, Apr 12, 2011 at 12:00 PM, Greg Smith wrote:
> Kevin Grittner wrote:
>>
>> Glyn Astill wrote:
>>
>>>
>>> Results from Greg Smiths stream_scaling test are here:
>>>
>>> http://www.privatepaste.com/4338aa1196
>>>
>>
>> Well, that pretty much clinches it. Your RAM access tops out at 16
>> p
Scott Marlowe wrote:
Have you tried running the memory stream benchmark Greg Smith had
posted here a while back? It'll let you know if you're memory is
bottlenecking. Right now my 48 core machines are the king of that
benchmark with something like 70+Gig a second.
The big Opterons are stil
Kevin Grittner wrote:
Glyn Astill wrote:
Results from Greg Smiths stream_scaling test are here:
http://www.privatepaste.com/4338aa1196
Well, that pretty much clinches it. Your RAM access tops out at 16
processors. It appears that your processors are spending most of
their time w
Hi,
I think that a NUMA architecture machine can solve the problem
A +
Le 11/04/2011 15:04, Glyn Astill a écrit :
Hi Guys,
I'm just doing some tests on a new server running one of our heavy select
functions (the select part of a plpgsql function to allocate seats)
concurrently. We do u
On Tue, Apr 12, 2011 at 6:40 PM, Kevin Grittner
wrote:
>
> Well, that pretty much clinches it. Your RAM access tops out at 16
> processors. It appears that your processors are spending most of
> their time waiting for and contending for the RAM bus.
It tops, but it doesn't drop.
I'd propose th
Glyn Astill wrote:
> Results from Greg Smiths stream_scaling test are here:
>
> http://www.privatepaste.com/4338aa1196
Well, that pretty much clinches it. Your RAM access tops out at 16
processors. It appears that your processors are spending most of
their time waiting for and contending fo
I have been wrestling with the configuration of the dedicated Postges 9.0.3
server at work and granted, there's more activity on the production server, but
the same queries take twice as long on the beefier server than my mac at home.
I have pasted what I have changed in postgresql.conf - I am w
On Tue, Apr 12, 2011 at 11:01 AM, Glyn Astill wrote:
> --- On Tue, 12/4/11, Merlin Moncure wrote:
>
>> >>> Can we see some iobound and cpubound pgbench
>> runs on both
>> >>> servers?
>> >>>
>> >>
>> >> Of course, I'll post when I've gotten to that.
>> >
>> > Ok, there's no writing going on -- so
--- On Tue, 12/4/11, Kevin Grittner wrote:
> Wow, zero idle and zero wait, and single digit for
> system. Did you
> ever run those RAM speed tests? (I don't remember
> seeing results
> for that -- or failed to recognize them.) At this
> point, my best
> guess at this point is that you don't ha
--- On Tue, 12/4/11, Merlin Moncure wrote:
> >>> Can we see some iobound and cpubound pgbench
> runs on both
> >>> servers?
> >>>
> >>
> >> Of course, I'll post when I've gotten to that.
> >
> > Ok, there's no writing going on -- so the i/o tets
> aren't necessary.
> > Context switches are also n
Glyn Astill wrote:
> Tried tweeking LOG2_NUM_LOCK_PARTITIONS between 5 and 7. My
> results took a dive when I changed to 32 partitions, and improved
> as I increaced to 128, but appeared to be happiest at the default
> of 16.
Good to know.
>> Also, if you can profile PostgreSQL at the sweet
Claudio Freire writes:
> Did you try increasing the statistic targets?
> AFAIK, it looks a lot like the planner is missing stats, since it
> estimates the index query on idx_nfi_newsfeed will fetch 10k rows -
> instead of 25.
BTW, this is the right suggestion, but for the wrong reason. You seem
"Ozer, Pam" wrote:
> I have two servers one has replication the other does not. The
> same query on both servers. One takes 225seconds on the
> replicated server the first time it runs and only 125ms on the
> other server the first time it runs. The second time you execute
> the query it drops
On Tue, Apr 12, 2011 at 8:23 AM, Merlin Moncure wrote:
> On Tue, Apr 12, 2011 at 3:54 AM, Glyn Astill wrote:
>> --- On Tue, 12/4/11, Merlin Moncure wrote:
>>
>>> >> The issue I'm seeing is that 8 real cores
>>> outperform 16 real
>>> >> cores, which outperform 32 real cores under high
>>> concur
On Tue, Apr 12, 2011 at 3:54 AM, Glyn Astill wrote:
> --- On Tue, 12/4/11, Merlin Moncure wrote:
>
>> >> The issue I'm seeing is that 8 real cores
>> outperform 16 real
>> >> cores, which outperform 32 real cores under high
>> concurrency.
>> >
>> > With every benchmark I've done of PostgreSQL, t
On 04/11/2011 03:11 PM, Lucas Madar wrote:
EXPLAIN ANALYZE SELECT * FROM objects INNER JOIN item f USING ( id );
This scans everything over everything, and obviously takes forever
(there are millions of rows in the objects table, and tens of thousands
in each itemXX table).
What is your const
--- On Mon, 11/4/11, Kevin Grittner wrote:
> From: Kevin Grittner
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: da...@lang.hm, "Steve Clark" , "Kevin Grittner"
> , "Glyn Astill"
> Cc: "Joshua D. Drake" , "Scott Marlowe"
> , pgsql-performance@postgresql.org
> Date: Monda
thank's a lot guys, I will try that out.
regards
Dieter
Am 12.04.2011 um 11:07 schrieb Claudio Freire:
On Tue, Apr 12, 2011 at 10:59 AM, Dieter Rehbein
wrote:
> I just executed a VACUUM ANALYZE and now everything performs well. hm,
> strange.
That probably means you need more statistics -
> On Tue, Apr 12, 2011 at 10:59 AM, Dieter Rehbein
> wrote:
>> I just executed a VACUUM ANALYZE and now everything performs well. hm,
>> strange.
>
> That probably means you need more statistics - try increasing the
> newsfeed's statistics target count.
>
> ALTER TABLE newsfeed_item ALTER COLUMN n
On Tue, Apr 12, 2011 at 10:59 AM, Dieter Rehbein
wrote:
> I just executed a VACUUM ANALYZE and now everything performs well. hm,
> strange.
That probably means you need more statistics - try increasing the
newsfeed's statistics target count.
ALTER TABLE newsfeed_item ALTER COLUMN newsfeed SET S
what I did, was an ANALYZE, which did not change anything.
I just executed a VACUUM ANALYZE and now everything performs well. hm, strange.
thanks
Dieter
Am 12.04.2011 um 09:42 schrieb Claudio Freire:
On Tue, Apr 12, 2011 at 7:20 AM, Dieter Rehbein
wrote:
> Hi everybody,
>
> I have a perfor
--- On Tue, 12/4/11, Scott Marlowe wrote:
> From: Scott Marlowe
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: "Glyn Astill"
> Cc: pgsql-performance@postgresql.org
> Date: Tuesday, 12 April, 2011, 6:55
> On Mon, Apr 11, 2011 at 7:04 AM, Glyn
> Astill
> wrote:
> > Hi Guys,
--- On Tue, 12/4/11, Merlin Moncure wrote:
> >> The issue I'm seeing is that 8 real cores
> outperform 16 real
> >> cores, which outperform 32 real cores under high
> concurrency.
> >
> > With every benchmark I've done of PostgreSQL, the
> "knee" in the
> > performance graph comes right around ((
Hi,
Anyone lucky to have dbt5 run for PostgreSQL 9.0.3?!
I am trying on Novell SuSE Linux Enterprise Server 11 SP1 x86_64 with a
virtual machine and bit hard with no success run yet. If you can help me
with any docs will be more of a support.
Regards,
Sethu Prasad
On Tue, Apr 12, 2011 at 7:20 AM, Dieter Rehbein
wrote:
> Hi everybody,
>
> I have a performance-problem with a query using a LIMIT. There are other
> threads rergading performance issues with LIMIT, but I didn't find useful
> hints for our problem and it might
> be interesting for other postgres
I actually implemented a statistical system for measuring these kinds
of correlations.
It's complex, but it might be adaptable to pgsql. Furthermore, one of
the latest projects of mine was to replace the purely statistical
approach with SVCs.
Too bad I won't be able to devote any time to that proj
On 11-4-2011 22:04 da...@lang.hm wrote:
in your case, try your new servers without hyperthreading. you will end
up with a 4x4 core system, which should handily outperform the 2x4 core
system you are replacing.
the limit isn't 8 cores, it's that the hyperthreaded cores don't work
well with the p
38 matches
Mail list logo
