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
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 pres
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 bro
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
-
Tom Lane 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 huge_table h (cost=0.00..5129
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
On May 25, 2006, at 4:11 PM, Tom Lane wrote:
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
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
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
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
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 remarka
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 stil
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:
>
"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 w
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
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
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 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 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;
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, and
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 tab
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 c
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
> > 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 l
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))
> >
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 w
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 ho
27 matches
Mail list logo
