On 10/31/10 12:28 PM, Radu Ilies wrote:
id, char[25]
name, text
The first row is:
id='radu'
name='Radu Ilies'
The following queries does not find any result (fail):
SELECT * FROM my_table WHERE id LIKE 'radu'
SELECT * FROM my_table WHERE id ILIKE 'radu'
'radu'::char[25] ==> 'radu__
The following bug has been logged online:
Bug reference: 5737
Logged by: Radu Ilies
Email address: ilies.r...@gmail.com
PostgreSQL version: 8.3.11
Operating system: NetBSD
Description:LIKE and ILIKE strange behaviour
Details:
Hello,
I have a table with:
id, char[2
On Fri, Oct 29, 2010 at 2:07 PM, Tom Lane wrote:
> [ please continue any further discussion in pgsql-bugs only ]
>
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> BTW this seems pretty far off-topic for pgsql-performance.
>
>> It is once you understand what's happening. It was probably the 11
Tom Lane writes:
> Also, make sure the ulimit command is effective in the shell that will
> actually launch the postmaster. This can be tricky if your PG launch
> script uses "su". If you're using the RH or PGDG RPMs' initscript,
> I'd suggest putting the ulimit command in ~postgres/.bash_profil
"Marcus Wirsing" writes:
> when I execute the following script, the planer always makes a seq. scan
> over all child tables.
> when I remove the min_mv real[] the planer makes an index scan as expected.
I see no bug here. Adding or removing a column changes the estimated
width of rows, hence the
