El día miércoles, enero 26, 2022 a las 11:21:12p. m. +0800, Julien Rouhaud
escribió:
> Hi,
>
> On Wed, Jan 26, 2022 at 11:07 PM Matthias Apitz wrote:
> >
> > We changed two relevant Indexes to
> >
> > CREATE INDEX d01ort ON d01buch(d01ort bpchar_pattern_ops );
> > CREATE INDEX d01ort2 ON d01buc
Hi,
On Wed, Jan 26, 2022 at 11:07 PM Matthias Apitz wrote:
>
> We changed two relevant Indexes to
>
> CREATE INDEX d01ort ON d01buch(d01ort bpchar_pattern_ops );
> CREATE INDEX d01ort2 ON d01buch(d01ort2 bpchar_pattern_ops );
When you said changed, did you drop the previous ones? As Tom
mention
We changed two relevant Indexes to
CREATE INDEX d01ort ON d01buch(d01ort bpchar_pattern_ops );
CREATE INDEX d01ort2 ON d01buch(d01ort2 bpchar_pattern_ops );
and now the same queries are fast. We're looking through our code for
more such LIKE clauses on VCHAR columns.
Thanks for all the hints
Julien Rouhaud writes:
> On Wed, Jan 26, 2022 at 02:34:21PM +0100, Dominique Devienne wrote:
>> On Wed, Jan 26, 2022 at 1:13 PM Julien Rouhaud wrote:
>>> That index can't be used with a LIKE that has a trailing wildcard.
>> So what makes you say that? --DD
> This part of the documentation you m
> We face in a PostgreSQL 11.4 installation on a potent Linux host a
> ...
> Why is this (ignoring the Index) and what could be done?
IMHO: 11.4 is very old. ( Release date: 2019-06-20 ) and missing a lot of
patches.
The latest patch release is 11.14 ( see
https://www.postgresql.org/docs/11/rele
Hi,
On Wed, Jan 26, 2022 at 02:34:21PM +0100, Dominique Devienne wrote:
> On Wed, Jan 26, 2022 at 1:13 PM Julien Rouhaud wrote:
> > > > > Why is this (ignoring the Index) and what could be done?
> > > [...]
> > > create INDEX d01ort on d01buch(d01ort) ;/* D01ORT*/
> >
> > That index can't b
On Wed, Jan 26, 2022 at 1:13 PM Julien Rouhaud wrote:
> > > > Why is this (ignoring the Index) and what could be done?
> > [...]
> > create INDEX d01ort on d01buch(d01ort) ;/* D01ORT*/
>
> That index can't be used with a LIKE that has a trailing wildcard.
Really? That seems to contradict th
Hi,
On Wed, Jan 26, 2022 at 12:39:25PM +0100, Matthias Apitz wrote:
>
> > > sisis=# explain (analyze, buffers) select * from d01buch where d01ort
> > > like 'Z 9610%' ;
> > > QUERY PLAN
> > >
El día miércoles, enero 26, 2022 a las 12:20:08 +0100, Josef Šimánek escribió:
> st 26. 1. 2022 v 11:55 odesílatel Matthias Apitz napsal:
> >
> >
> > Hello,
> >
> > We face in a PostgreSQL 11.4 installation on a potent Linux host a
> > serious performance degree.
> >
> > A SELECT with a LIKE clau
On Wed, Jan 26, 2022 at 11:55 AM Matthias Apitz wrote:
> A SELECT with a LIKE clause on a table with ca. 5.200.000 rows on a
> column with an Index ignores this and does a full table scan:
>
> sisis=# explain (analyze, buffers) select * from d01buch where d01ort like 'Z
> 9610%' ;
> -> Parallel S
st 26. 1. 2022 v 11:55 odesílatel Matthias Apitz napsal:
>
>
> Hello,
>
> We face in a PostgreSQL 11.4 installation on a potent Linux host a
> serious performance degree.
>
> A SELECT with a LIKE clause on a table with ca. 5.200.000 rows on a
> column with an Index ignores this and does a full tab
Hello,
We face in a PostgreSQL 11.4 installation on a potent Linux host a
serious performance degree.
A SELECT with a LIKE clause on a table with ca. 5.200.000 rows on a
column with an Index ignores this and does a full table scan:
sisis=# explain (analyze, buffers) select * from d01buch where
12 matches
Mail list logo
