Good day,
I have included a link to the result of EXPLAIN ANALYZE. It's this one:
https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h
https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h
Here's a link to Depesz's explain (if links to the site are okay):
http://explain.depesz.com/s/gCk
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of sl...@centrum.sk
Sent: Wednesday, August 07, 2013 8:43 AM
To: Pavel Stehule
Cc: pgsql-performance@postgresql.org
Subject: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a
You're right, it does... but it's quite odd, because I re-ran the
explain-analyze statement and got the same results.
Still, the query now runs for about a second as mentioned before, so it's
almost like something's missing from the explain, but I'm certain I copied it
all.
I did this via
From: sl...@centrum.sk [mailto:sl...@centrum.sk]
Sent: Wednesday, August 07, 2013 10:43 AM
To: Igor Neyman; Pavel Stehule
Cc: pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on
a view with another view inside of it.
You're right, it
2013/8/7 Igor Neyman iney...@perceptron.com:
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of sl...@centrum.sk
Sent: Wednesday, August 07, 2013 8:43 AM
To: Pavel Stehule
Cc: pgsql-performance@postgresql.org
Subject: [PERFORM] Re:
2013/8/7 sl...@centrum.sk:
You're right, it does... but it's quite odd, because I re-ran the
explain-analyze statement and got the same results.
Still, the query now runs for about a second as mentioned before, so it's
almost like something's missing from the explain, but I'm certain I
I got:
Total runtime: 9.313 ms in pgAdmin
Total runtime: 9.363 ms in psql.
But timing after the query finished was 912.842 ms in psql.
Cheers,
Peter Slapansky
__
Od: Igor Neyman iney...@perceptron.com
Komu: sl...@centrum.sk
Hi,
I've seen a couple of bad queries go through one instance and I'm wondering
whether there's something simple that can be done to help.
Not running the query in the first place is what I am looking to do
ultimately but in the meantime, I'm interested in understanding more about
the plan
From: sl...@centrum.sk [mailto:sl...@centrum.sk]
Sent: Wednesday, August 07, 2013 11:34 AM
To: Igor Neyman; Pavel Stehule
Cc: pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on
a view with another view inside of it.
I got:
Total
sl...@centrum.sk writes:
Total runtime: 9.313 ms in pgAdmin
Total runtime:Â 9.363 ms in psql.
But timing after the query finished was 912.842 ms in psql.
Well, that's the downside of increasing join_collapse_limit and
from_collapse_limit: you might get a better plan, but it takes a lot
longer
=?UTF-8?B?QWxleGlzIEzDqi1RdcO0Yw==?= a...@datadoghq.com writes:
The query itself is very simple: a primary key lookup on a 1.5x10^7 rows.
The issue is that we are looking up over 11,000 primary keys at once,
causing the db to consume a lot of CPU.
It looks like most of the runtime is probably
On Wed, Aug 7, 2013 at 12:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?UTF-8?B?QWxleGlzIEzDqi1RdcO0Yw==?= a...@datadoghq.com writes:
The query itself is very simple: a primary key lookup on a 1.5x10^7 rows.
The issue is that we are looking up over 11,000 primary keys at once,
causing the db
Let's say I have a table something like this:
create table call_activity (
id int8 not null,
called timestamp,
user_id int8 not null,
primary key (id)
foreign key (user_id) references my_users
)
I want to get the last call_activity record for a
On Wed, Aug 7, 2013 at 3:12 PM, Robert DiFalco robert.difa...@gmail.com wrote:
Let's say I have a table something like this:
create table call_activity (
id int8 not null,
called timestamp,
user_id int8 not null,
primary key (id)
foreign key
Claudio Freire klaussfre...@gmail.com writes:
On Wed, Aug 7, 2013 at 3:12 PM, Robert DiFalco robert.difa...@gmail.com
wrote:
I want to get the last call_activity record for a single user.
Create an index over (user_id, called desc), and do
select * from call_activity where user_id = blarg
-Original Message-
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-
performance-ow...@postgresql.org] On Behalf Of Claudio Freire
Sent: Wednesday, August 07, 2013 2:20 PM
To: Robert DiFalco
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Efficiently query for
Thanks guys!
On Wed, Aug 7, 2013 at 11:35 AM, Igor Neyman iney...@perceptron.com wrote:
-Original Message-
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-
performance-ow...@postgresql.org] On Behalf Of Claudio Freire
Sent: Wednesday, August 07, 2013 2:20 PM
To:
On Wed, Aug 7, 2013 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
On Wed, Aug 7, 2013 at 3:12 PM, Robert DiFalco robert.difa...@gmail.com
wrote:
I want to get the last call_activity record for a single user.
Create an index over (user_id,
Claudio Freire klaussfre...@gmail.com writes:
On Wed, Aug 7, 2013 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Note that there's no particular need to specify desc in the index
definition. This same index can support searches in either direction
on the called column.
Yeah, but it's faster
Claudio Freire escribió:
On Wed, Aug 7, 2013 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Note that there's no particular need to specify desc in the index
definition. This same index can support searches in either direction
on the called column.
Yeah, but it's faster if it's in the
On Wed, Aug 7, 2013 at 4:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, but it's faster if it's in the same direction, because the
kernel read-ahead code detects sequential reads, whereas it doesn't
when it goes backwards. The difference can be up to a factor of 10 for
long index scans.
21 matches
Mail list logo
