We are in the process of migrating from Oracle to Postgres and the following
query does much less work with Oracle vs Postgres.
explain (analyze, buffers)
select favoritegr0_.FAVORITE_GROUP_SID as favorite1_2_, favoritegr0_.CHANGED as
changed2_2_, favoritegr0_.TYPE_DISCRIMINATOR as type_dis3_2_,
I think this explains the situation well:
https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN
On Tue, Jun 14, 2022 at 11:59 AM Dirschel, Steve <
steve.dirsc...@thomsonreuters.com> wrote:
> We are in the process of migrating from Oracle to Postgres and the
> following query does muc
"Dirschel, Steve" writes:
> Is Postgres able to drive the query the same way with the NOT IN as the
> NOT EXISTS is doing or is that only available if the query has a NOT
> EXISTS?
NOT IN is not optimized very well in PG, because of the strange
semantics that the SQL spec demands when the sub-que
I am a bit confused as to the following change:
-
Stop using query-provided column aliases for the columns of whole-row
variables that refer to plain tables (Tom Lane)
The column names in tuples produced by a whole-row variable (such as
tbl.* in contexts other than the top level
Daniel Brinzila writes:
> I am a bit confused as to the following change:
>Stop using query-provided column aliases for the columns of whole-row
>variables that refer to plain tables (Tom Lane)
> Could someone please give an example of this scenario, one that works in
> 11.15 and another
"David G. Johnston" writes:
> On Tue, May 24, 2022 at 7:42 AM Tom Lane wrote:
>> Perhaps we could improve matters like this?
>> -specified, the underlying data type's default collation is used.
>> +specified, the domain has the same collation behavior as its
>> +underlyin
