Is there a way to avoid excessive inlining when writing pure SQL functions,
without having to use PL/pgSQL?
The JOIN LATERAL and Nested Subqueries versions run much slower than the
PL/pgSQL version:
Execution Times:
JOIN LATERAL: 12198.010 ms
Nested Subqueries: 12250.077 ms
PL/pgSQL: 312.493 ms
"Lu, Dan" writes:
> I am trying to upgrade an instance of PostgreSQL in unix from 11.5 to 12.1.
> UNIX:> pg_upgrade -d /hostname/pg/dpoc/data -D /hostname/pg/dpoc/data -b
> /hostname/pg/PostgreSQL-11.5/bin -B /hostname/pg/PostgreSQL-12.1/bin -p 5432
> -P 9432 -c -v
No, you can't use the same d
Hello PostgreSQL experts,
I am trying to upgrade an instance of PostgreSQL in unix from 11.5 to 12.1.
I got the following error on upgrade verification step.
Is this not allowed?
UNIX:> pg_upgrade -d /hostname/pg/dpoc/data -D /hostname/pg/dpoc/data -b
/hostname/pg/PostgreSQL-11.5/bin -B /host
Michael Lewis writes:
> On Fri, Dec 18, 2020 at 12:16 PM Tom Lane wrote:
>> Yeah, this is a fairly fundamental shortcoming in inheritance_planner():
>> it supposes that it can duplicate the whole query for each target table.
> Are there other examples of gotchas with this? Would it be any volati
On Fri, Dec 18, 2020 at 12:16 PM Tom Lane wrote:
> Laurenz Albe writes:
> > The subquery is executed twice, and the two executions obviously don't
> > return the same results. I am at a loss for an explanation ...
>
> Yeah, this is a fairly fundamental shortcoming in inheritance_planner():
> it
Gustavsson Mikael writes:
> pgsql-13 with require:
> $ /usr/pgsql-13/bin/psql "dbname=postgres user=kalle host=server
> sslmode=require"
> Password for user kalle:
> psql (13.1)
> Type "help" for help.
That is just bizarre. libpq should not ignore the sslmode=require option
like that, unless it
Laurenz Albe writes:
> The subquery is executed twice, and the two executions obviously don't
> return the same results. I am at a loss for an explanation ...
Yeah, this is a fairly fundamental shortcoming in inheritance_planner():
it supposes that it can duplicate the whole query for each targe
The following nicer work-around was suggested to me by Andreas Karlsson:
-jsonb_insert(x.jsonb_array,'{-1}',next_item.item,TRUE)
+x.jsonb_array || jsonb_build_array(next_item.item)
On Fri, Dec 18, 2020, at 17:20, Tom Lane wrote:
> "David G. Johnston" writes:
> > I'll agree that the desc
"David G. Johnston" writes:
> I'll agree that the description could discuss the case explicitly, and the
> array||scalar case could be added to the examples.
Yeah, the documentation completely fails to explain what happens
when the inputs aren't two arrays or two objects. I'd kind of assumed
tha
Hi,
We migrated from postgres 11 to 12 using logical replication (over local
network). Today we noticed that one table is missing 1252 rows after the
replication finished and we flipped to the new primary (we still have the
old master database so we can recover).
We see that these rows were inser
On Fri, Dec 18, 2020 at 8:24 AM Joel Jacobson wrote:
> The || operator for the jsonb type has a surprising behaviour.
>
> Instead of appending the right operand "as is" to the left operand,
> it has a magic behaviour if the right operand is an array,
> in which case it will append the items of th
The || operator for the jsonb type has a surprising behaviour.
Instead of appending the right operand "as is" to the left operand,
it has a magic behaviour if the right operand is an array,
in which case it will append the items of the array,
instead of appending the array itself as a single value
Would (task_type in (1,2)) make any logical difference?
On 12/18/20 6:11 AM, Craig McIlwee wrote:
Despite looking at this query on and off for a couple of days, it wasn't
until seeing it in Lauenz's reply that I noticed a logical issue with the
query that changes things a bit. There should be
Despite looking at this query on and off for a couple of days, it wasn't
until seeing it in Lauenz's reply that I noticed a logical issue with the
query that changes things a bit. There should be parenthesis around the
task_type predicates, otherwise you end up getting reserved rows in the
result
On Thu, 2020-12-17 at 12:21 -0500, Craig McIlwee wrote:
> Our application uses a queue-like table to assign tasks to users and this has
> worked well for us for a few years. Now we are in the process of adding some
> restrictions to which tasks a user can
> work on and that is based on an attrib
Hi,
We migrated from postgres 11 to 12 using logical replication. Today we
noticed that one table is missing 1252 rows after the replication finished
and we flipped to the new primary (we still have the old so we can recover).
We see that these rows were inserted in the table after starting the
i
Hi,
I did some more tests to try to narrow it down. For me it only added to the
confusion but maybe it tells you something.
Test 1:
I changed my pg_hba.conf from hostssl to host.
Now I can connect but SSL is not used even if i use require.
pgsql-13:
$ /usr/pgsql-13/bin/psql -d postgres -Uk
17 matches
Mail list logo
