of
> pg_upgrade; amcheck; upgrade all extensions; amcheck;
> would make sense.
>
Is it possible to amcheck gist indexes?..
--
Victor Yegorov
able,
this is especially true for the append-only tables.
After the delete, planning queries takes a long time, due to MergeJoin
estimates
are using IndexScans ( see
https://postgr.es/m/17467.1426090...@sss.pgh.pa.us )
Right now we have to disable MergeJoins via the ALTER SYSTEM to mitigate
this.
So I would, actually, like it very much for VACUUM to kick in sooner in
such cases.
--
Victor Yegorov
provides a better estimate for the usefulness of the operation.
I suppose that 1% threshold should be configurable as a cluster-wide GUC
and also as a table storage parameter?
--
Victor Yegorov
indexes supporting
FK constraints
on highly skewed sets, with 80% of the index belonging to a single value
(say, huge business
customer vs several thousands of one-time buyers).
--
Victor Yegorov
ly flagged), this
can
have some positive effects.
Also, I'm not sure where to put it. We've deprecated the BTP_HAS_GARBAGE
flag, maybe it can be reused for this purpose?
--
Victor Yegorov
Again, this is my understanding and I hope I got it right.
--
Victor Yegorov
e to rewrite requests in a form:
/cgit/*/commit/*
into
/cgit/*/commit/?id=&
?
--
Victor Yegorov
2c
silently shows another commit.
Is it possible to make the scheme above work?
Our gitweb (and also github) is using it, so I assume people are quite used
to it.
--
Victor Yegorov
I
> want "make installcheck" to pass that specifically accounts for this
> (and a few other similar things).
>
Oh, right, haven't thought of this. Thanks for pointing that out.
Now everything looks good!
--
Victor Yegorov
this.
Therefore I didn't perform any tests here, will wait for the next version.
--
Victor Yegorov
20210111-v13-regression.diffs
Description: Binary data
ught?
>
Honestly, I was thinking that this will not be backpatched at all
and really am glad we're getting this fixed in the back branches as well.
Therefore I think it's fine to skip 9.5, though I
would've mentioned this in the commit message.
--
Victor Yegorov
Which makes me
think, that current
master is quite good at keeping better bloat control (not sure if this is
an effect of
4228817449 commit or deduplication).
I created another setup (see attached testcases). Basically, I emulated
queue operations(INSERT at the end and DELETE
--
Victor Yegorov
er has it in his patch.
Yes, it's possible to shorten this part. But readability is hurt — for
current code I just read it, for the suggested change I need to think about
it.
--
Victor Yegorov
look into this patch in the next few days.
--
Victor Yegorov
e for the project.
If I understand things right, session will release it's locks
when max_standby_streaming_delay is reached.
But it'd be much better if conflict is resolved faster,
around deadlock_timeout.
So — huge +1 from me for fixing it.
--
Victor Yegorov
question about
how this works
(trying to clear up gaps in my understanding).
What I meant to ask — will LP_DEAD be set by IndexScan in the presence of
the long transaction?
--
Victor Yegorov
ry promising improvement!
I haven't done any testing so far since sending my last e-mail.
If you'll have a chance to send a new v10 version with
LP_DEAD-deletion-with-extra-TIDs thing,
I will do some tests (planned).
--
Victor Yegorov
ing purposes, and saves callers the trouble of
> telling _bt_delitems_delete() (and code like it) whether or not this
> is a heapkeyspace index.
>
OK. Can you explain what deprecation means here?
If this functionality is left as is, it is not really deprecation?..
--
Victor Yegorov
, with a high rate of INSERTs+DELETEs and a long
transaction.
Currently I've seen such conditions yield indexes of several GB in size
wil holding less
than a thousand of live records.
- upgraded cluster with !heapkeyspace indexes.
--
Victor Yegorov
robably help here,
> too.
>
I don't quite see this part. Do you mean top_block_groups_favorable() here?
--
Victor Yegorov
flag in the functions above, we can get
rid of blocks that drop it
in _bt_delitems_delete(), I think.
--
Victor Yegorov
I would rather add a comment, explaining that the empty body of the
clause is actually expected.
7. In the _bt_dedup_delete_finish_pending() you're setting ispromising to
false for both
posting and non-posting tuples. This contradicts comments before
function.
--
Victor Yegorov
was some work in this area for 14, see
https://git.postgresql.org/pg/commitdiff/44fc6e259b
--
Victor Yegorov
difficult to look into.
Peter, according to cfbot patch no longer compiles.
Can you send and update, please?
--
Victor Yegorov
s reproduces the error I get. One needs to create ltree
extension first.
I understand, that issue most likely comes from the length of the ltree
data stored in the columns.
But error is a bit misleading…
--
Victor Yegorov
lc.pgdump
Description: Binary data
in ~50% of the cases.
I would like to find out what's the real cause here, but I am not sure how
to do it.
If anybody could provide some guidance, I am open to investigate this case.
I'm on PostgreSQL 11.8 (Debian 11.8-1.pgdg90+1), debugging symbols
installed.
--
Victor Yegorov
ole table (well, not really, but
still) to find the operator.
--
Victor Yegorov
stgreSQL provides only infrastructure, wrappers for different
remote systems are not supported by the PostgreSQL community,
except for postgres_fdw and csv_fdw provided by the project.
--
Victor Yegorov
stgresql.org/message-id/cab7npqtys6juqdxuczbjb0bnw0kprw8wdzuk11kaxqq6o98...@mail.gmail.com
- 2013
https://www.postgresql.org/message-id/cab7npqstfkuc7dzxcdx4hotu63yxhrronv2aouzyd-zz_8z...@mail.gmail.com
- https://commitfest.postgresql.org/16/1276/
--
Victor Yegorov
29 matches
Mail list logo
