2010/4/9 Greg Smith :
> RD黄永卫 wrote:
>>
>> Anybody have the test case of “ context-switching issue on Xeon” from
>> Tm lane ？
>>
>
> That takes me back:
> http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
>
> That's a problem seen on 2004 era Xeon processors, and with PostgreSQL
2010/4/9 Greg Smith :
> RD黄永卫 wrote:
>>
>> Anybody have the test case of “ context-switching issue on Xeon” from
>> Tm lane ？
>>
>
> That takes me back:
> http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
>
> That's a problem seen on 2004 era Xeon processors, and with PostgreSQL
Brian Cox writes:
> I saw this in the postgres log. Anyone know what would cause this?
> Thanks, Brian
> postgres 8.3.5 on RHEL4 update 6
> [3358-cemdb-admin-2010-04-09 04:00:19.029 PDT]ERROR: could not open
> relation with OID 170592
Seems a bit off-topic for pgsql-performance, but anyway: t
RD黄永卫 wrote:
>
> Anybody have the test case of “ context-switching issue on Xeon” from
> Tm lane ？
>
That takes me back:
http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
That's a problem seen on 2004 era Xeon processors, and with PostgreSQL
7.4. I doubt it has much relevance
On Tue, Apr 6, 2010 at 8:42 PM, norn wrote:
> I have some mysterious slow downs with ORDER BY and LIMIT. When LIMIT
> getting greater than some value (greater than 3 in my case), query
> takes 4-5 secs instead of 0.25ms. All of the necessary indexes are in
> place. I have no idea what to do, so an
I have just a function returning a cursor based on a single coplex query.
When I check the execution plan of that query it takes about 3 seconds. Just
when it is used inside the function it freezes.
This is the problem, and this is the reason I cannot imagine what is happen.
Also I tried to rec
Hi，
Anybody have the test case of “ context-switching issue on Xeon” from Tm lane ？
Best regards,
Ray Huang
Kevin, thanks for your attention!
I've read SlowQueryQuestions, but anyway can't find bottleneck...
Here requested information:
OS: Ubuntu 9.10 64bit, Postgresql 8.4.2 with Postgis
Hardware: AMD Phenom(tm) II X4 945, 8GB RAM, 2 SATA 750GB (pg db
installed in software RAID 0)
Please also note that
I saw this in the postgres log. Anyone know what would cause this?
Thanks, Brian
postgres 8.3.5 on RHEL4 update 6
[3358-cemdb-admin-2010-04-09 04:00:19.029 PDT]ERROR: could not open
relation with OID 170592
[3358-cemdb-admin-2010-04-09 04:00:19.029 PDT]STATEMENT: select
lm.ts_login_name,sm.t
On Fri, Apr 9, 2010 at 1:02 PM, Jesper Krogh wrote:
> It would be nice if there was an easy way to test and confirm that it
> actually was robust to power-outtake..
Sadly, the only real test is pulling the power plug. And it can't
prove the setup is good, only that it's bad or most likely good.
On 2010-04-09 20:22, Greg Smith wrote:
Jesper Krogh wrote:
I've spent quite some hours googling today. Am I totally wrong if the:
HP MSA-20/30/70 and Sun Oracle J4200's:
https://shop.sun.com/store/product/53a01251-2fce-11dc-9482-080020a9ed93
are of the same type just from "major" vendors.
Yes,
Jesper Krogh wrote:
I've spent quite some hours googling today. Am I totally wrong if the:
HP MSA-20/30/70 and Sun Oracle J4200's:
https://shop.sun.com/store/product/53a01251-2fce-11dc-9482-080020a9ed93
are of the same type just from "major" vendors.
Yes, those are the same type of implementati
On Fri, Apr 9, 2010 at 10:30 AM, Merlin Moncure wrote:
> On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith wrote:
>> The main problem with this configuration is that work_mem is set to an
>> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
>> free after starting the server, w
On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith wrote:
> The main problem with this configuration is that work_mem is set to an
> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
> free after starting the server, work_mem='4MB' is as large as you can safely
> set this.
if y
On Fri, Apr 9, 2010 at 10:03 AM, Greg Smith wrote:
> The main problem with this configuration is that work_mem is set to an
> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
> free after starting the server, work_mem='4MB' is as large as you can safely
> set this.
> m
On 2010-04-09 17:27, Greg Smith wrote:
Jesper Krogh wrote:
Can someone shed "simple" light on an extremely simple question.
How do you physicallly get 48 drives attached to an LSI that claims to
only have 2 internal and 2 external ports?
(the controller claims to support up to 240 drives).
The
Off-list message that should have made it onto here, from Krzysztof:
I have changed PostgreSQL to 8.3. I think that the database is really working
faster. New settings:
name | unit | current_setting
-+--+---
autova
Jesper Krogh wrote:
Can someone shed "simple" light on an extremely simple question.
How do you physicallly get 48 drives attached to an LSI that claims to
only have 2 internal and 2 external ports?
(the controller claims to support up to 240 drives).
There are these magic boxes that add "SAS e
The OP is using:
autovacuum_vacuum_threshold | 10
That means that vacuum won't consider a table to be 'vacuum-able' until
after 100k changes that's nowhere near aggressive enough. Probably
what's happening is that when autovacuum finally DOES start on a table, it
just takes forever.
2010/4/9 Greg Smith :
> Merlin Moncure wrote:
>>
>> postgresql 8.2: autovacuum enabled by default
>> postgresql 8.3: HOT (reduces update penalty -- zabbix does a lot of
>> updates)
>>
>
> autovacuum wasn't enabled by default until 8.3. It didn't really work all
> that well out of the box until the
On Fri Apr 9 2010 8:18 AM, Sabin Coanda wrote:
I have just a function returning a cursor based on a single coplex query.
When I check the execution plan of that query it takes about 3 seconds. Just
when it is used inside the function it freezes.
This is the problem, and this is the reason I cann
21 matches
Mail list logo
