Luke Lonergan wrote:
On 11/7/07 10:21 PM, "Gregory Stark" <[EMAIL PROTECTED]> wrote:
part=# explain SELECT * FROM n_traf ORDER BY date_time LIMIT 1;
QUERY PLAN
--
"Mark Kirkwood" <[EMAIL PROTECTED]> writes:
> Here is a (somewhat hurried) self-contained version of the patch under
> discussion. It applies to 8.2.5 and the resultant code compiles and runs. I've
> left in some unneeded parallel stuff (PathLocus struct), which I can weed out
> in a subsequent ve
On 11/7/07 10:21 PM, "Gregory Stark" <[EMAIL PROTECTED]> wrote:
>> part=# explain SELECT * FROM n_traf ORDER BY date_time LIMIT 1;
>> QUERY PLAN
>> -
>> ---
Gregory Stark wrote:
"Mark Kirkwood" <[EMAIL PROTECTED]> writes:
I spent today looking at getting this patch into a self contained state.
Working against HEAD I'm getting bogged down in the PathKeyItem to
PathKey/EquivalenceClass/EquivalenceMember(s) change. So I figured I'd divide
and conqu
On 11/8/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I've applied a patch that might help you:
> http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php
Thanks. I'll build a RPM package tomorrow with this patch and let you
know if it fixes the problem.
--
Guillaume
On 11/7/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wanted the locale (lc_collate), not the encoding.
fr_FR.UTF-8
> That would optimize this particular query and probably pessimize
> a lot of others.
Sure but there aren't a lot of queries based on the ancestors field
and if they are a bit slower
I wrote:
> "Guillaume Smet" <[EMAIL PROTECTED]> writes:
>> [ bad estimate for LIKE ]
> Hmmm ... what locale are you working in? I notice that the range
> estimator for this pattern would be "ancestors >= '1062/' AND
> ancestors < '10620'", which will do the right thing in C locale
> but maybe not
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On 11/7/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Hmmm ... what locale are you working in? I notice that the range
>> estimator for this pattern would be "ancestors >= '1062/' AND
>> ancestors < '10620'", which will do the right thing in C locale
>>
On 11/7/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmmm ... what locale are you working in? I notice that the range
> estimator for this pattern would be "ancestors >= '1062/' AND
> ancestors < '10620'", which will do the right thing in C locale
> but maybe not so much elsewhere.
Sorry for not hav
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> [ bad estimate for LIKE ]
Hmmm ... what locale are you working in? I notice that the range
estimator for this pattern would be "ancestors >= '1062/' AND
ancestors < '10620'", which will do the right thing in C locale
but maybe not so much elsewhere.
>>> On Mon, Nov 5, 2007 at 10:42 AM, in message
<[EMAIL PROTECTED]>, "Campbell,
Lance" <[EMAIL PROTECTED]> wrote:
> How can I [. . .] get rid of some unnecessary indexes
Here's what I periodically run to look for unused indexes:
select relname, indexrelname
from pg_stat_user_indexes
where
Alexander,
On 11/7/07, Alexander Staubo <[EMAIL PROTECTED]> wrote:
> That's a difference of less than *three milliseconds* -- a difference
> probably way within the expected overhead of running "explain
> analyze". Furthermore, all three queries use the same basic plan: a
> sequential scan with a
On 11/7/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> While studying a query taking forever after an ANALYZE on a never
> analyzed database (a bad estimate causes a nested loop on a lot of
> tuples), I found the following problem:
[snip]
> Total runtime: 31.097 ms
[snip]
> Total runtime: 31.341
Hi all,
While studying a query taking forever after an ANALYZE on a never
analyzed database (a bad estimate causes a nested loop on a lot of
tuples), I found the following problem:
- without any stats (I removed the line from pg_statistic):
ccm_prod_20071106=# explain analyze select * from cms_ite
14 matches
Mail list logo
