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
the publisher, 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
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
and casting the json column to jsonb before comparing for equality.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> 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
> 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:
>
ead nothing;
CREATE RULE
rules=# update 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
reset 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
all regexp_replace multiple 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
told to grab and not try to grab the ",someone", but
other than that, they 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
> 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
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
> 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
XCLUDE USING gist (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
14 matches
Mail list logo
