Good day
I’ve got a performance and best practice question. We’re busy writing our
persistence framework for our application port to PostgreSQL.
We have business entities that are split over multiple tables and in an
effort to not have multiple trips to the database we’re trying to batch
these
Thanks for the fast reply and explanation, Tom. Overall, I have been
pleasantly surprised with the leniency of indexes on range types.
On Sat, May 20, 2017 at 5:00 PM, Tom Lane wrote:
> Zac Goldstein writes:
> > This uses the index:
> > ...
> > But this doesn't:
>
> > EXPLAIN (ANALYZE, BUF
Zac Goldstein writes:
> This uses the index:
> ...
> But this doesn't:
> EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM shot
> WHERE lower(shot.matchsecond) <@ ((shot.matchsecond).match_id,
> numrange(5, 10))::matchsecond_type;
Well, yeah. After inlining the SQL functions, what you have is
>
Hello,
The index on my composite type seems to be working most of the time, but
there's a query I need to run where it's not working even with
enable_seqscan=false. The composite type uses int and numrange subcolumns,
and is designed to operate primarily as a range type.
It will probably be easi
