"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> Basically it looks like planner makes better use of
> WHERE ... IS NOT NULL indexes if either you explicitly
> put "text" as a column type or that you cast the column
> to ::text when making index.
I've applied a patch for this.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Running it myself I do see the same behaviour in 8.3. I'm not sure whether
> this is something we expect to work or not though.
It looks like it might be relatively easy to fix, but I haven't dug down
to find exactly where things go wrong. Presumably th
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> If I may suggest it -- try to run the queries yourself. You will find the
> problem lies not in the statistics.
I was more concerned that there might be other discrepancies between the
commands in the email and the actual commands you're running.
R
On 7/24/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> Now, if we:
>
> # EXPLAIN ANALYZE SELECT t FROM foo WHERE t='X17';
>QUERY PLAN
>
--
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> Now, if we:
>
> # EXPLAIN ANALYZE SELECT t FROM foo WHERE t='X17';
>QUERY PLAN
> ---
> Seq Scan on foo (cost=0
On 7/24/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> ALTER TABLE foo ALTER COLUMN i TYPE text;
> EXPLAIN SELECT * FROM foo WHERE i=17;
> QUERY PLAN
> ---
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> ALTER TABLE foo ALTER COLUMN i TYPE text;
> EXPLAIN SELECT * FROM foo WHERE i=17;
> QUERY PLAN
> -
> Bitmap Heap Scan on foo (cost=12.14..554.
Hello, I guess I've stuck upon one problem with (I guess) implicit
casting varchar to text...
Basically it looks like planner makes better use of
WHERE ... IS NOT NULL indexes if either you explicitly
put "text" as a column type or that you cast the column
to ::text when making index.
Here's a s
