On Fri, Jan 14, 2011 at 7:59 PM, Kevin Grittner wrote:
> Tom Lane wrote:
>
> > Shaun's example is a bit off
>
> > As for speed, either one might be faster in a particular
> > situation.
>
> After fixing a mistake in my testing and learning from Tom's example
> I generated queries against the OP'
Tom Lane wrote:
> Shaun's example is a bit off
> As for speed, either one might be faster in a particular
> situation.
After fixing a mistake in my testing and learning from Tom's example
I generated queries against the OP's test data which produce
identical results, and I'm finding no signi
"Kevin Grittner" writes:
> Shaun Thomas wrote:
>> This actually looks like a perfect candidate for DISTINCT ON.
>>
>> SELECT DISTINCT ON (a, b) a, b, revision
>> FROM test
>> ORDER BY a, b DESC;
> I wouldn't say perfect. It runs about eight times slower than what
> I suggested and returns a f
Shaun Thomas wrote:
> This actually looks like a perfect candidate for DISTINCT ON.
>
> SELECT DISTINCT ON (a, b) a, b, revision
>FROM test
> ORDER BY a, b DESC;
I wouldn't say perfect. It runs about eight times slower than what
I suggested and returns a fairly random value for revisio
On 01/14/2011 03:17 PM, Nikolas Everett wrote:
SELECT *
FROM request
JOIN (SELECT a, MAX(b) as b FROM test GROUP BY a) max USING (a)
JOIN test USING (a, b);
This actually looks like a perfect candidate for DISTINCT ON.
SELECT DISTINCT ON (a, b) a, b, revision
FROM test
ORDER BY a,
Nikolas Everett wrote:
> I'm really going to be doing this with an arbitrary list of As.
OK, how about this?:
CREATE TEMPORARY TABLE request (a INTEGER NOT NULL);
INSERT INTO request SELECT a FROM generate_series(2, 200) AS t(a);
ANALYZE request;
SELECT y.*
from (select a, max(revision) as
On Fri, Jan 14, 2011 at 23:19, Chris Browne wrote:
> 2. In 9.1, there will be a new answer, as there's a GUC to indicate the
> "application_name".
Actually this was already introduced in PostgreSQL 9.0 :)
You can add application_name to your log_line_prefix with %a. For
pg_dump it will display
On Fri, Jan 14, 2011 at 5:30 PM, Kevin Grittner wrote:
> SELECT y.*
> from (select a, max(revision) as revision
> from test where a between 2 and 200
> group by a) x
> join test y using (a, revision);
While certainly simpler than my temp table this really just exposes a flaw
Nikolas Everett wrote:
> Am I missing something or is this really the best way to do this in
8.3?
How about this?:
SELECT y.*
from (select a, max(revision) as revision
from test where a between 2 and 200
group by a) x
join test y using (a, revision);
-Kevin
--
Sen
msakre...@truviso.com (Maciek Sakrejda) writes:
>> Is this normal? I'm afraid because my application doesn't run this kind of
>> statement, so how can I know what is doing these commands? Maybe pg_dump?
>
> I think pg_dump is likely, yes, if you have that scheduled. I don't
> think anything in the
I'm using 8.3 and I have a table that contains many revisions of the same
entity and I have a query that is super slow. Please help! I'm going to
paste in some SQL to set up test cases and some plans below. If that isn't
the right way to post to this list please let me know and I'll revise.
My
> Is this normal? I'm afraid because my application doesn't run this kind of
> statement, so how can I know what is doing these commands? Maybe pg_dump?
I think pg_dump is likely, yes, if you have that scheduled. I don't
think anything in the log file will identify it as pg_dump explicitly
(I beli
On Thu, Jan 13, 2011 at 6:10 PM, Tom Lane wrote:
> Jon Nelson writes:
>> On Thu, Jan 13, 2011 at 5:05 PM, Tom Lane wrote:
>>> If you have enough memory to de-dup them individually, you surely have
>>> enough to de-dup all at once.
>
>> If everything were available up-front, sure.
>> However, and
Hi there,
I have one log file per week and logging all statements >= 500 ms execution
time.
But, with "normal" statements are occuring something like this:
2011-01-13 00:11:38 BRT LOG: duration: 2469.000 ms statement: FETCH 1000
IN bloboid
2011-01-13 00:12:01 BRT LOG: duration: 797.000 ms stat
On Tue, Jan 11, 2011 at 3:16 AM, Rauan Maemirov wrote:
> Hi, Kevin.
> Sorry for long delay.
> EXPLAIN ANALYZE SELECT "v"."id", "v"."title" FROM "video" AS "v"
> WHERE (v.active) AND (v.fts @@
> 'dexter:A|season:A|seri:A|декстер:A|качество:A|сезон:A|серия:A'::tsquery and
> v.id <> 500563 )
> ORDER
2011/1/10 Mladen Gogala :
> Well, I really hoped that Bruce, Robert or Greg would take on this one, but
> since there are no more qualified takers, I'll take a shot at this one. For
> the "NOT IN (result of a correlated sub-query)", the sub-query needs to be
> executed for every row matching the co
On Fri, Jan 14, 2011 at 11:36 AM, Mike Broers wrote:
> Thanks Robert, this is what I was looking for. I will try these suggestions
> and follow up if any of them are the silver bullet.
No problem - and sorry for the off-list reply. I was a little sleepy
when I wrote that; thanks for getting it
Craig Ringer wrote:
On 01/12/2011 10:16 PM, Guillaume Cottenceau wrote:
What's your point and in what is it related to that ML?
Given the package names, I suspect this is a poorly-expressed complaint
about the performance of downloads from the pgdg/psqlrpms site. If that
was the ori
Thanks Robert, this is what I was looking for. I will try these suggestions
and follow up if any of them are the silver bullet.
On Fri, Jan 14, 2011 at 7:11 AM, Robert Haas wrote:
> On Thu, Jan 6, 2011 at 4:36 PM, Mike Broers wrote:
> > Thanks for the assistance.
> > Here is an explain analyze
14.01.11 00:26, Tom Lane написав(ла):
Robert Haas writes:
On Thu, Jan 13, 2011 at 3:12 PM, Jon Nelson wrote:
I still think that having UNION do de-duplication of each contributory
relation is a beneficial thing to consider -- especially if postgresql
thinks the uniqueness is not very high.
T
20 matches
Mail list logo
