On 2022-03-29 19:08:44 -0700, David G. Johnston wrote:
> On Tue, Mar 29, 2022 at 6:30 PM Paul Jungwirth
> wrote:
>
> I noticed that this runs your pager:
>
> psql -f <(echo 'select * from pg_class;')
>
> but not this:
>
> echo 'select * from pg_class;' | psql
[...]
>
On Tue, Mar 29, 2022 at 6:30 PM Paul Jungwirth
wrote:
> I noticed that this runs your pager:
>
> psql -f <(echo 'select * from pg_class;')
>
> but not this:
>
> echo 'select * from pg_class;' | psql
>
> Indeed running the pager for -f but not stdin seems opposite of the last
> line of t
Hello,
I noticed that this runs your pager:
psql -f <(echo 'select * from pg_class;')
but not this:
echo 'select * from pg_class;' | psql
A client encountered this when the psql command run from their deb's
.postinst file started to hang.
We can prevent it with PSQL_PAGER='', but i
> On Mar 29, 2022, at 2:24 PM, Tom Lane wrote:
>
> Philip Semanchuk writes:
>> I have a function that isn't being inlined, and I would appreciate help to
>> understand why that's the case.
>
> I think the test methodology you used is faulty, because it does not
> distinguish between "inlin
Philip Semanchuk writes:
> I have a function that isn't being inlined, and I would appreciate help to
> understand why that's the case.
The example you show *is* inline-able, as you can easily prove with EXPLAIN.
regression=# CREATE OR REPLACE FUNCTION f(foo text)
RETURNS text
AS $$
SEL
Hi all,
I have a function that isn't being inlined, and I would appreciate help to
understand why that's the case.
I'm using PG 11.15. I know that if I declare my function IMMUTABLE and it calls
a non-IMMUTABLE function, Postgres won't inline my function. But even when my
function calls only s
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2022-Mar-22, Shukla, Pranjal wrote:
> > Are there any disadvantages of increasing the “wal_keep_segments” to a
> > higher number say, 500? Will it have any impact on performance of
> > streaming replication, on primary or secondary
Thanks a lot Magnus for the reply.
I understand that jsonb_path_ops creates index on the whole path or on all
the attributes.
Does it takes more storage or reduces write performance in comparison to
normal gin index ?
On Tue, Mar 29, 2022 at 2:19 PM Magnus Hagander wrote:
>
>
> On Tue, Mar 29,
No matter what you do, you will not typically get the same level of
performance as normalized tables as you do not get statistics on the values
stored in your jsonb column. No knowledge of null fraction, number of
distinct values, or most common values and their frequencies.
On Tue, Mar 29, 2022 at 7:06 AM Saurav Sarkar
wrote:
> Hi All,
>
> We use JSONB /NoSQL functionality of PostgreSQL.
>
> One of the column "doc" in our table "Table1" is of type JSONB.
>
> Now the rows in this column "doc" can have different values with different
> schemas.
>
> For e.g values of d
10 matches
Mail list logo
