SELECT toode, nimetus
FROM toode
WHERE toode ILIKE 'x10%' ESCAPE '!'
ORDER BY UPPER(toode ),nimetus LIMIT 100
runs 1 minute in first time for small table size.
Toode field type is CHAR(20)
1) why are you using CHAR and not VARCHAR or TEXT? CHAR will give you
problems using
Andrus [EMAIL PROTECTED] writes:
1) why are you using CHAR and not VARCHAR or TEXT? CHAR will give you
problems using an index, period.
1. I haven't seen any example where VARCHAR is better that CHAR for indexing
The advice you were given is good, even if the explanation is bad.
CHAR(n) is
On Mon, 2006-06-05 at 17:06 -0400, Tom Lane wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jun 05, 2006 at 04:07:19PM -0400, Tom Lane wrote:
I'm wondering about out-of-date or nonexistent ANALYZE stats, missing
custom adjustments of statistics target settings, etc.
But even
On Tue, 2006-06-06 at 10:43 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-06-05 at 17:06 -0400, Tom Lane wrote:
Well, it's a big query. If it ought to take a second or two, and
instead is taking an hour or two (1800 times the expected runtime), that
might be
On Mon, Jun 05, 2006 at 01:39:38PM -0700, Chris Beecroft wrote:
Thanks Tom,
I knew you would come through again!
Query is now returning with results on our replicated database. Will
vacuum analyze production now. So it seems to have done the trick. Now
the question is has our auto
Simon Riggs [EMAIL PROTECTED] writes:
You mentioned it would be good if the OP had delivered an EXPLAIN
ANALYZE; I agree(d). The lack of EXPLAIN ANALYZE is frequently because
you can't get them to run to completion - more so when the query you
wish to analyze doesn't appear to complete either.
On Tue, Jun 06, 2006 at 11:06:09AM -0400, Tom Lane wrote:
The idea I just had was: why do we need EXPLAIN ANALYZE to run to
completion? In severe cases like this thread, we might be able to
discover the root cause by a *partial* execution of the plan, as long as
it was properly
On Tue, Jun 06, 2006 at 11:06:09AM -0400, Tom Lane wrote:
it was properly instrumented. That way, the OP might have been able to
discover the root cause himself...
I don't think that helps, as it just replaces one uncertainty by
another: how far did the EXPLAIN really get towards
Simon Riggs [EMAIL PROTECTED] writes:
The idea I just had was: why do we need EXPLAIN ANALYZE to run to
completion? In severe cases like this thread, we might be able to
discover the root cause by a *partial* execution of the plan, as long as
it was properly instrumented. That way, the OP
Simon Riggs wrote:
Well, it's a big query. If it ought to take a second or two, and
instead is taking an hour or two (1800 times the expected runtime), that
might be close enough to never to exhaust Chris' patience. Besides,
we don't know whether the 1800 might itself be an underestimate (too
Tom Lane wrote:
The idea I just had was: why do we need EXPLAIN ANALYZE to run to
completion? In severe cases like this thread, we might be able to
discover the root cause by a *partial* execution of the plan, as long as
it was properly instrumented. That way, the OP might have been able to
On Tue, 2006-06-06 at 12:50, Craig A. James wrote:
Tom Lane wrote:
The idea I just had was: why do we need EXPLAIN ANALYZE to run to
completion? In severe cases like this thread, we might be able to
discover the root cause by a *partial* execution of the plan, as long as
it was properly
Andrew Sullivan wrote:
On Thu, Jun 01, 2006 at 01:54:08PM +0200, Antoine wrote:
Hi,
We just don't seem to be getting much benefit from autovacuum. Running
a manual vacuum seems to still be doing a LOT, which suggests to me
that I should either run a cron job and disable autovacuum, or just
run
Mischa Sandberg wrote:
Andrew Sullivan wrote:
On Thu, Jun 01, 2006 at 01:54:08PM +0200, Antoine wrote:
Hi,
We just don't seem to be getting much benefit from autovacuum. Running
a manual vacuum seems to still be doing a LOT, which suggests to me
that I should either run a cron job and disable
Joshua D. Drake wrote:
- in our env, clients occasionally hit max_connections. This is a
known and (sort of) desired pushback on load. However, that sometimes
knocks pg_autovacuum out.
That is when you use:
superuser_reserved_connections
Blush. Good point. Though, when we hit
On Tue, Jun 06, 2006 at 12:54:27PM -0500, Scott Marlowe wrote:
On Tue, 2006-06-06 at 12:50, Craig A. James wrote:
Tom Lane wrote:
The idea I just had was: why do we need EXPLAIN ANALYZE to run to
completion? In severe cases like this thread, we might be able to
discover the root cause by
On Tue, 2006-06-06 at 15:51, Jim C. Nasby wrote:
On Tue, Jun 06, 2006 at 12:54:27PM -0500, Scott Marlowe wrote:
On Tue, 2006-06-06 at 12:50, Craig A. James wrote:
Tom Lane wrote:
The idea I just had was: why do we need EXPLAIN ANALYZE to run to
completion? In severe cases like this
Scott Marlowe [EMAIL PROTECTED] writes:
The cost of not aborting on the first sort is that you may never see
what the part of the plan is that's killing your query, since you never
get the actual plan.
Well, you can get the plan without waiting a long time; that's what
plain EXPLAIN is for.
On Tue, 2006-06-06 at 16:11, Tom Lane wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
The cost of not aborting on the first sort is that you may never see
what the part of the plan is that's killing your query, since you never
get the actual plan.
Well, you can get the plan without
Tom Lane wrote:
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.
I agree that that particular author seems clueless, but
20 matches
Mail list logo
