On Thu, Oct 5, 2023 at 4:25 PM Lauri Kajan wrote:
> In my dreams the plan would be something like this:
> Nested Loop
> -> Index Scan using dealers_pkey on dealers
> Index Cond: (id = ANY ('{54,12,456,315,468}'::integer[]))
> -> Append
>
On Thu, Oct 5, 2023 at 12:30 PM Marian Wendt wrote:
>
> With an INNER JOIN, both tables must be fully checked/matched (check
using EXPLAIN ANALYSIS -> HashJoin), so the index cannot be used here.
> Sorry, didn't consider the WITH part. Please share the detailed query
plan for more info.
Now, it r
Hi,
Is it intended that indexes are not pushed down to union all
subqueries if even a single select contains a where clause? Is this
just not implemented, is it impossible to implement or am I doing
something wrong?
The following query does a SeqScan for "bikes" and "cars" tables even
though Inde
Thank you Jon and Tom!
Both of those ideas seem to work.
Do you think this is worth of a feature request? Would there be any use if
btree index is used in these certain situations directly with @>?
Thanks,
Lauri
On Wed, Nov 27, 2019 at 1:05 PM Игорь Выскорко
wrote:
> Hi!
> Do you use GIST index?
> According to
> https://www.postgresql.org/docs/12/rangetypes.html#RANGETYPES-INDEXING <@
> operator is supported:
> > A GiST or SP-GiST index can accelerate queries involving these range
> operators: =, &&, <@,
Hi all,
I'm wondering if there are anything to do to utilize a index when doing a
range contains element query. I have tested this with 9.6 and 12.0.
I have a table with a timestamp column that has a btree index.
I would like to do a query:
SELECT * FROM table WHERE ts <@ tsrange($1, $2, '(]');
T