Pierre C wrote:
> > Does the psql executable have any ability to do a "fetch many", using a
> > server-side named cursor, when returning results? It seems like it tries
> > to retrieve the query entirely to local memory before printing to
> > standard out.
>
> I think it grabs the whole resu
RD黄永卫 wrote:
> My database server get sluggish suddenly
> [vmstat output showing over 200,000 context switches per second]
>My postgres version: 8.1.3;
Upgrading should help. Later releases are less vulnerable to this.
> Could you please give me some advice ?
A connection pooler c
norn wrote:
> I restarted Postgresql with new settings and got no performance
> improvements in this particular query...
The cost settings help the optimizer make good decisions about plan
choice. I guess I don't have much reason to believe, at this point,
that there is a better plan for it t
2010/4/12 RD黄永卫 :
> I donnt know what make the "context-switching" storm ？
>
> How should I investigate the real reason ?
>
> Could you please give me some advice ?
It might be because of cascading locks so try to monitor them when it happens.
You may find this query useful:
SELECT
granted
Kevin,
I appreciate your help very much!
> Since the LIMIT 3 and LIMIT 4 queries generated exactly the same
> plan, the increased time for LIMIT 4 suggests that there are 3
> matching rows which are near the end of the index it is scanning, but
> the fourth one is much farther in.
Yes, you are rig
Hi，
My database server get sluggish suddenly ，I check the vmstat as below：
2010-04-07 04:03:15 procs memory swap io
system cpu
2010-04-07 04:03:15 r b swpd free buff cache si sobibo
incs us sy id wa
2010-04-07 14
Thank you for you reply!
“one of the indicators of that is that context switches per second will
start to jump up and the machine gets
Sluggish”
--> Here is my database server indicator:
These is ther VMSTAT log of my database server as below:
2010-04-07 04:03:15 pro
On Sun, 2010-04-11 at 23:12 +0200, Corin wrote:
> Hi,
>
> I'm having a query where the planer chooses a very bad plan.
>
> explain analyze SELECT * FROM "telegrams" WHERE ((recipient_id=508933
> AND recipient_deleted=FALSE) OR (user_id=508933 AND user_deleted=FALSE))
> ORDER BY id DESC LIMIT 10
Hi, here are they:
select * from t_route_type;
ID;description;type
1;"stojim";0
2;"idem";1
explain analyze
SELECT * FROM t_route
WHERE t_route.route_type_fk = 1
limit 4;
"
On Apr 10, 6:48 am, robertmh...@gmail.com (Robert Haas) wrote:
> 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
"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 cannot imagine w
On Sat, Apr 10, 2010 at 4:47 PM, Ben Chobot wrote:
> My understanding is that this generally happens because the plan should be
> different for the different values, but the first time the function is run it
> caches the plan for one of the values and will never use the appropriate plan
> for t
[rearranging to put related information together]
norn
Since the LIMIT 3 and LIMIT 4 queries generated exactly the same
plan, the increased time for LIMIT 4 suggests that there are 3
matching rows which are near the end of the index it is scanning, but
the fourth one is much farther in.
Sinc
Andrey,
- Another idea for your problem is the one Kevin gave in the message following:
##
> SELECT * FROM t_route
> WHERE t_route.route_type_fk = 1
> limit 4;
This
explain analyze SELECT * FROM "telegrams" WHERE ((recipient_id=508933
AND recipient_deleted=FALSE) OR (user_id=508933 AND user_deleted=FALSE))
ORDER BY id DESC LIMIT 10 OFFSET 0
If you need very fast performance on this query, you need to be able to
use the index for ordering.
Note that
15 matches
Mail list logo
