Re: TEXT column > 1Gb

ou currently hit, but then you are still at an impasse. Would a factor or 2x or 4x be enough for your needs? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value

the subscriber might not bother creating indexes over that data, even if such indexes exist on the publisher. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Logical Replication - Should Destination Table Columns Be Defined With Default Value

executed. Instead, the default value will be returned the next time the row is accessed, and applied when the table is rewritten, making the ALTER TABLE very fast even on large tables. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Determining if a table really changed in a trigger

asting the json column to jsonb before comparing for equality. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Determining if a table really changed in a trigger

> On Oct 26, 2021, at 3:39 PM, Mitar wrote: > > On Tue, Oct 26, 2021 at 10:55 PM Mark Dilger > wrote: >> Note that there is a performance cost to storing the old rows using the >> REFERENCING clause of the trigger > > Yea, by moving the trivial update check

Re: Determining if a table really changed in a trigger

> On Oct 26, 2021, at 1:34 PM, Mitar wrote: > > Hi! > > On Tue, Oct 26, 2021 at 10:17 PM Mark Dilger > wrote: >> I can't tell from your post if you want the trivial update to be performed, >> but if not, would it work to filter trivial updates as: > >

Re: Determining if a table really changed in a trigger

my_table set j = '{"key":2}'::jsonb; UPDATE 0 rules=# update my_table set j = '{"key":3}'::jsonb; WARNING: [old.i=1, old.j={"key": 2}] => [new.i=1, new.j={"key": 3}] WARNING: [old.i=2, old.j={"key": 2}] => [new.i=2, new.j={"key": 3}] WARNING: [old.i=3, old.j={"key": 2}] => [new.i=3, new.j={"key": 3}] UPDATE 3 — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: gen_random_uuid key collision

the seed for your random generator. I haven't looked specifically at your uuid generator, and I don't know if it gets nondeterministic randomness from /dev/random or similar, but deterministic random generators can be made to produce the same sequence again if the seed it reset. — Ma

Re: [E] Regexp_replace bug / does not terminate on long strings

le times until all repeats are eradicated, but I don't think such workarounds should be necessary. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [E] Regexp_replace bug / does not terminate on long strings

y should be performing the same work. I don't see why the performance should be so different. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Do table-level CHECK constraints affect the query optimizer?

> On Jun 29, 2021, at 11:02 AM, Ron wrote: > > What's an IOS? An Index Only Scan. See https://www.postgresql.org/docs/14/indexes-index-only-scans.html — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Do table-level CHECK constraints affect the query optimizer?

You might want to run VACUUM FREEZE and then retry your test query using EXPLAIN. See if it switches to an index only scan after the VACUUM FREEZE. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Struggling with EXCLUDE USING gist

> On Jun 4, 2021, at 11:55 AM, Laura Smith > wrote: > > That seems to have done the trick. Thanks again Mark Glad to hear it. Good luck. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Struggling with EXCLUDE USING gist

st (t_val WITH=, t_range WITH &&) DEFERRABLE INITIALLY > DEFERRED > ); > INSERT INTO test(t_val) values(p_val); This will insert a t_range of ('-infinity','infinity'), won't it? Wouldn't you want to instead insert with t_range starting around now() rather than starting at -in