В ответ на:

---

получение колонок id, foo, bar, baz не может быть выполнено только из индекса testi, т.к. там хранятся только колонки id, bar. Обязательно еще должен быть запрос к кластерному индексу для получения колонок foo, baz.
Либо testi является кластерным индексом, но тогда понятно почему план запросов всегда делается через него.

---

Quote:

---

Обязательно еще должен быть запрос к кластерному индексу для получения колонок foo, baz.

---

Quote:

---

в первой строке плана heap scan. Heap это и есть сама таблица.

---

Quote:

---

можешь дальше продолжать верить в магию.

---

В ответ на:

---

1) select * from test where (:id is null or id = :id) and (:bar is null or bar = :bar);

---

Query.New(
    p => {
        var q = new Q("select a.*");

        IQuery<IRecord> result;
        if (p.b)
        {
            q._(", b.id as id_b");
            result = q.Query<IBRecord>();
        }
        else
            result = q.Query<IARecord>();

        q._(" from ");

        if (p.c)
            q._("c as a");
        else
            q._("a");

        if (p.b)
            q._(" inner join b on b.id = a.id ");

        q._(" where 1 = 1");

        if (p.d)
            q._(" and a.type_id = 1");
        return result;
    },
    new {b, c, d}
    ).Execute();

interface IRecord
{
    T Match<T>(Func<IARecord, T> a, Func<IBRecord, T> b);
}

private interface IARecord : IRecord
{
    int id { get; }
    int type_id { get; }
}

private interface IBRecord : IARecord
{
    int id_b { get; }
}

В ответ на:

---

Сегодня я проверил это на постгресе:

---

В ответ на:

---

This is another situation where EXECUTE can be used to force a new plan to be generated for each execution.

---

Quote:

---

Долго думал как может работать эта черная магия.

---

В ответ на:

---

This is another situation where EXECUTE can be used to force a new plan to be generated for each execution.
  

---

В ответ на:

---

специально для вас все расписали, как раз PostgreSQL

---

В ответ на:

---

Allow the planner to generate custom plans for specific parameter values even when using prepared statements (Tom Lane)

In the past, a prepared statement always had a single "generic" plan that was used for all parameter values, which was frequently much inferior to the plans used for non-prepared statements containing explicit constant values. Now, the planner attempts to generate custom plans for specific parameter values. A generic plan will only be used after custom plans have repeatedly proven to provide no benefit. This change should eliminate the performance penalties formerly seen from use of prepared statements (including non-dynamic statements in PL/pgSQL).
  

---

Quote:

---

Это старая статья. Мой пример работает начиная с версии 9.2.

---

Quote:

---

проблема не разрешима в принципе

---

Quote:

---

explain execute testq(1234456);

---