Hi,
I find this very helpful:
Lowering the priority of a PostgreSQL query
http://weblog.bignerdranch.com/?p=11
Now I was wondering whether one could have a
SELECT pg_setpriority(10);
executed automatically each time a certain user
connects (not necessarily using psql)?
Any ideas if and
Chris Mair [EMAIL PROTECTED] writes:
I find this very helpful:
Lowering the priority of a PostgreSQL query
http://weblog.bignerdranch.com/?p=11
That guy doesn't actually have the foggiest idea what he's doing.
The reason there is no built-in capability to do that is that it *does
not work
On 5/24/06, Tom Lane [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
Limit (cost=19676.75..21327.99 rows=6000 width=84)
- Hash Join (cost=19676.75..1062244.81 rows=3788315 width=84)
Hash Cond: (upper((outer.id)::text) upper((inner.id)::text))
- Seq Scan on
I find this very helpful:
Lowering the priority of a PostgreSQL query
http://weblog.bignerdranch.com/?p=11
That guy doesn't actually have the foggiest idea what he's doing.
The reason there is no built-in capability to do that is that it *does
not work well*. Search the list
On Thu, May 25, 2006 at 12:31:04PM -0400, [EMAIL PROTECTED] wrote:
Well, they're not my statistics; they're explain's. You mean there's
Explain doesn't get them from nowhere. How often is the table being
ANALYSEd?
More bewildering still (and infuriating as hell--because it means that
all of
On Thu, May 25, 2006 at 06:16:24PM +0200, Chris Mair wrote:
I find this very helpful:
Lowering the priority of a PostgreSQL query
http://weblog.bignerdranch.com/?p=11
Now I was wondering whether one could have a
SELECT pg_setpriority(10);
executed automatically each time a certain
On 5/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Well, they're not my statistics; they're explain's. You mean there's
a bug in explain? I agree that it makes no sense that the costs don't
differ as much as one would expect, but you can see right there the
numbers of rows for the two
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
select a,b,max(c) from t group by a,b;
t has an index on a,b,c.
in my sample case with cardinality of 1000 for a, 2000 for b,
On Thu, May 25, 2006 at 16:07:19 -0400,
Merlin Moncure [EMAIL PROTECTED] wrote:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
select a,b,max(c) from t group by a,b;
t
On 5/25/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
On Thu, May 25, 2006 at 16:07:19 -0400,
Merlin Moncure [EMAIL PROTECTED] wrote:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal
On Thu, May 25, 2006 at 04:07:19PM -0400, Merlin Moncure wrote:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
select a,b,max(c) from t group by a,b;
t has an index on
On May 25, 2006 01:31 pm, Merlin Moncure [EMAIL PROTECTED] wrote:
SELECT DISTINCT ON (a, b) a, b, c FROM t ORDER BY a DESC, b DESC, c
DESC;
that is actually slower than group by in my case...am i missing
something? (both essentially resolved to seq_scan)
Try it with an index on a,b,c.
--
On Thu, May 25, 2006 at 16:31:40 -0400,
Merlin Moncure [EMAIL PROTECTED] wrote:
On 5/25/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
On Thu, May 25, 2006 at 16:07:19 -0400,
Merlin Moncure [EMAIL PROTECTED] wrote:
been doing a lot of pgsql/mysql performance testing lately, and there
is
Merlin Moncure [EMAIL PROTECTED] writes:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
select a,b,max(c) from t group by a,b;
t has an index on a,b,c.
The index won't
On 5/25/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote:
On Thu, May 25, 2006 at 04:07:19PM -0400, Merlin Moncure wrote:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
On Thu, May 25, 2006 at 04:54:09PM -0400, Merlin Moncure wrote:
select a,b,(select c from t t2 order by c desc where t1.a=t2.a and
t1.b=t2.b)
from t t1 group by a,b;
this came out to a tie with the group by approach, although it
produced a different (but similar) plan. we are still
Tom Lane [EMAIL PROTECTED] writes:
Merlin Moncure [EMAIL PROTECTED] writes:
recent versions of mysql do much better, returning same set in 20ms.
Well, since they don't do MVCC they can answer this query from the
index without going to the heap at all. But that still seems remarkably
fast
On Thu, 2006-05-25 at 15:52, Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
select a,b,max(c) from t group by
On Thu, 2006-05-25 at 16:52 -0400, Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
been doing a lot of pgsql/mysql performance testing lately, and there
is one query that mysql does much better than pgsql...and I see it a
lot in normal development:
select a,b,max(c) from t
On May 25, 2006, at 12:07 PM, Dawid Kuroczko wrote:
On 5/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Well, they're not my statistics; they're explain's. You mean there's
a bug in explain? I agree that it makes no sense that the costs
don't
differ as much as one would expect, but you
Jim Nasby [EMAIL PROTECTED] writes:
On May 25, 2006, at 4:11 PM, Tom Lane wrote:
Are you sure you measured that right? I tried to duplicate this using
mysql 5.0.21, and I see runtimes of 0.45 sec without an index and
0.15 sec with. This compares to psql times around 0.175 sec. Doesn't
look
That guy doesn't actually have the foggiest idea what he's doing.
The reason there is no built-in capability to do that is that it *does
not work well*. Search the list archives for priority inversion to
find out why not.
http://en.wikipedia.org/wiki/Priority_inversion
Also, are you sure your numbers are not coming out of the mysql query
cache?
That might explain some of it - also with Tom seeing comprable
numbers in his test.
--
Jeff Trout [EMAIL PROTECTED]
http://www.jefftrout.com/
http://www.stuarthamm.net/
---(end of
Jeff - [EMAIL PROTECTED] writes:
Also, are you sure your numbers are not coming out of the mysql query
cache?
That might explain some of it - also with Tom seeing comprable
numbers in his test.
Indeed, enabling the mysql query cache makes the timings drop to
nil ... as long as I present a
On 5/25/06, Tom Lane [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
Merlin Moncure [EMAIL PROTECTED] writes:
recent versions of mysql do much better, returning same set in 20ms.
Are you sure you measured that right? I tried to duplicate this using
mysql 5.0.21, and I see
25 matches
Mail list logo
