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
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
[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
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
"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 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
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 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
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
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
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
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
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
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
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
15 matches
Mail list logo
