patrick ~ wrote:
[...]
pkk=# explain analyze execute pkk_01(241 );
QUERY PLAN
-
Result
patrick ~ wrote:
Hi John,
Thanks for your reply and analysis.
No problem. It just happens that this is a problem we ran into recently.
--- John Meinel [EMAIL PROTECTED] wrote:
patrick ~ wrote:
[...]
Hmm... The fact is I am selecting (in this example anyway) over all
values in pkk_offer table
patrick ~ wrote:
Hi John,
Thanks for your reply and analysis.
--- John Meinel [EMAIL PROTECTED] wrote:
patrick ~ wrote:
[...]
pkk=# explain analyze execute pkk_01(241 );
QUERY PLAN
One other thing that I just thought of. I think it is actually possible
to add an index on a function
Jaime Casanova wrote:
[...]
In http://www.postgresql.org/docs/faqs/FAQ.html under
4.8) My queries are slow or don't make use of the
indexes. Why? says:
However, LIMIT combined with ORDER BY often will use
an index because only a small portion of the table is
returned. In fact, though MAX() and
Jaime Casanova wrote:
[...]
I'm not sure. They all return the same information.
of course, both queries will return the same but
that's just because you forced it.
LIMIT and DISTINCT are different things so they behave
and are plenned different.
What's also weird is stuff like:
SELECT
Curt Sampson wrote:
On Sun, 24 Oct 2004, John Meinel wrote:
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed...
The real purpose of this query is to check to see if a value exists
Rod Dutton wrote:
Hi,
Has anybody got any ideas on my recent posting ? (thanks in advance) :-
I have a problem where a query inside a function is up to 100 times
slower inside a function than as a stand alone query run in psql.
The column 'botnumber' is a character(10), is indexed and
Rod Dutton wrote:
Thank John,
I am running Postgres 7.3.7 on a Dell PowerEdge 6600 Server with Quad Xeon
2.7GHz processors with 16GB RAM and 12 x 146GB drives in Raid 10 (OS, WAL,
Data all on separate arrays).
You might want think about upgraded to 7.4, as I know it is better at
quite a few
Rod Dutton wrote:
I also should add that the sp is only slow when the table is big (probably
obvious!).
Rod
Sure, the problem is it is switching to a sequential search, with a lot
of rows, versus doing an indexed search.
It's all about trying to figure out how to fix that, especially for any
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Without the LIMIT, this query should definitely do
a sequential
Tom Lane wrote:
John Meinel [EMAIL PROTECTED] writes:
I was looking into another problem, and I found something that surprised
me. If I'm doing SELECT * FROM mytable WHERE col = 'myval' LIMIT 1..
Now col is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Without
Francisco Reyes wrote:
On Mon, 11 Oct 2004, Janning Vygen wrote:
[...]
When I saw the default explain I was surprised to see that indexes were
not been used. For example the join on lines 4,5 are exactly the primary
key of the tables yet a sequential scan was used.
Note this:
The default
Dustin Sallings wrote:
[...]
OK, now that that's over with, I have this one particular query that
I attempt to run for a report from my phone that no longer works because
it tries to do a table scan on *some* of the tables. Why it chooses
this table scan, I can't imagine. The query is as
Tom Lane wrote:
John Meinel [EMAIL PROTECTED] writes:
... However, if I try to
bundle this query up into a server side function, it runs very slow (10
seconds). I'm trying to figure out why, but since I can't run EXPLAIN
ANALYZE inside a function, I don't really know what else to do
Richard Huxton wrote:
John Meinel wrote:
So notice that when doing the actual select it is able to do the index
query. But for some reason with a prepared statement, it is not able
to do it.
Any ideas?
In the index-using example, PG knows the value you are comparing to. So,
it can make
Tom Lane wrote:
[ enlarging on Richard's response a bit ]
John Meinel [EMAIL PROTECTED] writes:
jfmeinel= explain analyze execute myget(3);
QUERY PLAN
Seq Scan on tdata (cost
16 matches
Mail list logo
