Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Susan Russo wrote:
>> Next step is to initdb w/C Locale (tonight) (Thanks Tom et al.!).
> That's alternative to the pattern_ops index; it won't help you obtain a
> plan faster than this one.
No, but since their old DB was evidently running in C locale,
Susan Russo wrote:
> Hi,
>
> >You could always try
> >
> > CREATE INDEX test_index ON dbxref (accession varchar_pattern_ops);
>
> WOW! we're now at runtime 0.367ms on Pg8
>
> Next step is to initdb w/C Locale (tonight) (Thanks Tom et al.!).
That's alternative to the pattern_ops index; it won'
:48:34 +0200
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
To: Susan Russo <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org, [EMAIL PROTECTED]
Subject: Re: [PERFORM] specific query (not all) on Pg8 MUCH slower than Pg7
Mail-Followup-To: Susan Russo <[EMAIL PROTECTED]&
"Alexander Staubo" <[EMAIL PROTECTED]> writes:
> why is there no support for changing the database locale after the fact?
It'd corrupt all your indexes (or all the ones on textual columns anyway).
There are some TODO entries related to this, but don't hold your breath
waiting for a fix ...
In response to "Alexander Staubo" <[EMAIL PROTECTED]>:
> On 5/8/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > You're not getting the indexscan optimization of the LIKE clause, which
> > is most likely due to having initdb'd the 8.1 installation in something
> > other than C locale. You can either r
On 5/8/07, Tom Lane <[EMAIL PROTECTED]> wrote:
You're not getting the indexscan optimization of the LIKE clause, which
is most likely due to having initdb'd the 8.1 installation in something
other than C locale. You can either redo the initdb in C locale (which
might be a good move to fix other
--- Susan Russo <[EMAIL PROTECTED]> wrote:
> and accession like 'AY851043%'
I don't know if you've tried refactoring your query, but you could try:
AND accession BETWEEN 'AY8510430' AND 'AY8510439' -- where the last digit is
^ ^ -- l
On Tue, May 08, 2007 at 10:18:34AM -0400, Susan Russo wrote:
> explain analyze output on Pg7.3.2:
>
>-> Index Scan using dbxref_idx2 on dbxref dx
> (cost=0.00..5.83 rows=1 width=21) (actual time=25.58..25.58 rows=0 loops=1)
> Index Cond: ((accession >= 'AY85
Susan Russo <[EMAIL PROTECTED]> writes:
> Despite numerous efforts, we're unable to solve a severe performance
> limitation between Pg 7.3.2
> and Pg 8.1.4.
> The query and 'explain analyze' plan below, runs in
> 26.20 msec on Pg 7.3.2, and
> 2463.968 ms on Pg 8.1.4,
You're not ge
Hi,
Despite numerous efforts, we're unable to solve a severe performance limitation
between Pg 7.3.2
and Pg 8.1.4.
The query and 'explain analyze' plan below, runs in
26.20 msec on Pg 7.3.2, and
2463.968 ms on Pg 8.1.4,
and the Pg7.3.2 is on older hardware and OS.
Multiply
10 matches
Mail list logo
