nks much!
>
> Xuefeng Zhu (Sherry)
> Crown Consulting Inc. -- Oracle DBA
> AIM Lab Data Team
> (703) 925-3192
>
>
>
> *Joel Jacobson *
>
> 04/06/2010 06:30 PM
> To
> Sherry CTR Zhu/AWA/CNTR/f...@faa, pgsql-performance@postgresql.org
> cc
> Robe
Subject
> Re: [PERFORM] LIMIT causes planner to do Index Scan using a less
> optimal
> indexLink
>
>
>
> Have you tried before?
>
> Thanks much!
>
> Xuefeng Zhu (Sherry)
> Crown Consulting Inc. -- Oracle DBA
> AIM Lab Data Team
> (703) 925-3192
>
>
>
On Wed, 7 Apr 2010, sherry.ctr@faa.gov wrote:
Please just let me know if Postgres can do this kind of index or not.
create index idx1 on tb1(col1, col2)
Then later we can find it is useful or useless.
Have you tried it?
Grzegorz Jaśkiewicz wrote:
something like this: create index id
by: pgsql-performance-ow...@postgresql.org
04/07/2010 09:12 AM
To
Sherry CTR Zhu/AWA/CNTR/f...@faa
cc
Joel Jacobson , pgsql-performance@postgresql.org,
Robert Haas
Subject
Re: [PERFORM] LIMIT causes planner to do Index Scan using a less optimal
index
2010/4/7
Do you mean one index on
2010/4/7
>
> Do you mean one index on two columns?
>
> something like this: create index idx1 on tb1(col1, col2);
>
yup :) It would be quite useless without that feature.
Don't listen to oracle folks, they obviously know not much about products
others than oracle db(s).
--
GJ
Jacobson , pgsql-performance@postgresql.org,
Robert Haas
Subject
Re: [PERFORM] LIMIT causes planner to do Index Scan using a less optimal
index
On Wed, Apr 7, 2010 at 1:20 PM, wrote:
Guys,
Thanks for trying and opening your mind.
If you want to know how Oracle addressed this
On Wed, Apr 7, 2010 at 1:20 PM, wrote:
>
> Guys,
>
> Thanks for trying and opening your mind.
> If you want to know how Oracle addressed this issue, here it is: index
> on two columns. I remember that they told me in the training postgres has
> no this kind of index, can someone clarify?
>
Inc. -- Oracle DBA
AIM Lab Data Team
(703) 925-3192
Joel Jacobson
04/06/2010 06:30 PM
To
Sherry CTR Zhu/AWA/CNTR/f...@faa, pgsql-performance@postgresql.org
cc
Robert Haas
Subject
Re: [PERFORM] LIMIT causes planner to do Index Scan using a less optimal
index
Actually, swapping the
On Tue, Apr 6, 2010 at 6:30 PM, Joel Jacobson wrote:
> Actually, swapping the order of the conditions did in fact make some
> difference, strange.
>
> I ran the query a couple of times for each variation to see if the
> difference in speed was just a coincidence or a pattern. Looks like the
> spe
On Fri, Apr 2, 2010 at 2:19 PM, Joel Jacobson wrote:
> Is this a bug? I'm using version 8.4.1.
It's not really a bug, but it's definitely not a feature either.
> Limit (cost=0.00..43.46 rows=1 width=4) (actual time=1023.213..1023.214
> rows=1 loops=1)
> -> Index Scan using transactions_pke
I came across a strange problem when writing a plpgsql function.
Why won't the query planner realize it would be a lot faster to use the
"index_transactions_accountid_currency" index instead of using the
"transactions_pkey" index in the queries below?
The LIMIT 1 part of the query slows it down fr
11 matches
Mail list logo
