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 fu
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
patrick ~ wrote:
[...]
pkk=# explain analyze execute pkk_01(241 );
QUERY PLAN
-
Result (cost=2.
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
Tom Lane wrote:
Curtis Zinzilieta <[EMAIL PROTECTED]> writes:
On Tue, 26 Oct 2004, Tom Lane wrote:
Er ... it *is* the other way around. bi is blocks in (to the CPU),
bo is blocks out (from the CPU).
Ummm.
[EMAIL PROTECTED] T2]$ man vmstat
bi: Blocks sent to a block device (blocks/s).
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 DISTINCT(NU
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 i
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
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 sequenti
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
va
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 things
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 t
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 explain
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:
[ enlarging on Richard's response a bit ]
John Meinel <[EMAIL PROTECTED]> writes:
jfmeinel=> explain analyze execute myget(3);
QUERY PLAN
Seq
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 a
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 kno
17 matches
Mail list logo
