So even in a north-american locale, such as en_CA this will be a
problem?
Dave
On Thu, 2003-12-18 at 22:44, Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > after vacuum verbose analyze, I still get [a seqscan]
>
> The other gating factor is that you have to have initdb'd in C locale
Tom Lane wrote:
No, they are not that easy to determine. In particular I think the idea
of automatically feeding back error measurements is hopeless, because
you cannot tell which parameters are wrong.
Isn't it just a matter of solving an equation system with n variables (n
being the number of pa
Dave Cramer <[EMAIL PROTECTED]> writes:
> So even in a north-american locale, such as en_CA this will be a
> problem?
If it's not "C" we won't try to optimize LIKE. I know en_US does not
work (case-insensitive, funny rules about spaces, etc) and I would
expect en_CA has the same issues.
If you'r
"Marinos J. Yannikos" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, they are not that easy to determine. In particular I think the idea
>> of automatically feeding back error measurements is hopeless, because
>> you cannot tell which parameters are wrong.
> Isn't it just a matter of solvin
Hello,
i got indexes to work with "text_pattern_ops" for locale et_EE.
So instead of:
create index some_index_name on some_table(some_text_field);
nor
create index some_index_name on some_table(some_text_field text_ops);
try to create index as follows:
create index some_index_name on some_
Tom Lane wrote:
easy or cheap to get a measurement that isn't skewed by kernel caching
behavior. (You need a test file significantly larger than RAM, and
even then you'd better repeat the measurement quite a few times to see
how much noise there is in it.)
I found a really fast way in Linux to flu
