a benchmarking in the thread
> showed a good result. I'd appreciate your input on that thread.
Certainly, I will stop this thread and contribute to Yura's thread.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Mon, 17 Jan 2022 at 09:05, Jeff Davis wrote:
>
> On Wed, 2022-01-05 at 20:19 +, Simon Riggs wrote:
> > I spoke with Jeff in detail about this patch in NYC Dec 21, and I now
> > think it is worth pursuing. It seems much more likely that this would
> > be acceptab
the Delete after the
Insert?
Put that another way, it looks like BufTable functions are used in a
way that mismatches against the way dynahash is designed.
Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
g removed.
v3 attached.
--
Simon Riggshttp://www.EnterpriseDB.com/
hibernate_to_reduce_power_consumption.v3.patch
Description: Binary data
On Sat, 19 Feb 2022 at 17:03, Andres Freund wrote:
>
> Hi,
>
> On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> > Some years ago we did a pass through the various worker processes to
> > add hibernation as a mechanism to reduce power consumption on an idle
> >
behavior is preserved.
Patch to do all of the above attached.
Comments please.
--
Simon Riggshttp://www.EnterpriseDB.com/
hibernate_to_reduce_power_consumption.v1.patch
Description: Binary data
the command you have suggested, where the user should be able to
> SET & RESET multiple
> options in a single command for an object.
I prefer ADD/DROP to SET/RESET. The latter doesn't convey the meaning
accurately to me.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 11 Feb 2022 at 19:08, Andres Freund wrote:
> On 2022-02-11 13:48:59 +0000, Simon Riggs wrote:
> > On Fri, 11 Feb 2022 at 08:48, Simon Riggs
> > wrote:
> > >
> > > On Fri, 11 Feb 2022 at 06:11, Andres Freund wrote:
> > >
> > > >
On Fri, 11 Feb 2022 at 08:48, Simon Riggs wrote:
>
> On Fri, 11 Feb 2022 at 06:11, Andres Freund wrote:
>
> > Looks lik syncrep will make this a lot worse, because it can drastically
> > increase the window between the TransactionIdCommitTree() and
> > Pr
t might make it easier to write tests exercising this scenario...
Agreed
TransactionIdIsKnownCompleted(xid) is only broken because the single
item cache is set too early in some cases. The single item cache is
important for performance, so we just need to be more careful about
setting the cache.
--
On Thu, 27 Jan 2022 at 06:58, Michael Paquier wrote:
>
> On Wed, Nov 03, 2021 at 04:59:04PM +, Simon Riggs wrote:
> > Thanks. Fixed and rebased.
>
> + if (xact_info == XLOG_XACT_PREPARE)
> + {
> + if (rec
need all locks. DDL would request the lock in exclusive
mode. (Other mechanisms possible).
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 18 Jan 2022 at 08:10, Amit Langote wrote:
>
> Hi Simon,
>
> On Tue, Jan 18, 2022 at 4:44 PM Simon Riggs
> wrote:
> > On Tue, 11 Jan 2022 at 16:22, Robert Haas wrote:
> > > This is just a relatively simple example and I think there are
> > > prob
ow important this is. Thanks.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 30 Nov 2021 at 12:19, Simon Riggs wrote:
>
> On Mon, 30 Aug 2021 at 11:25, Andrey Borodin wrote:
> >
> > Hi Pengcheng!
> >
> > You are solving important problem, thank you!
> >
> > > 30 авг. 2021 г., в 13:43, Pengchengliu
> > &g
we
discuss the main approach.
2. Write up the approach in a detailed README, so people can
understand the proposal and assess if there are problems. A few short
notes and a link back to old conversations isn't enough to allow wide
review and give confidence on such a major patch.
--
iction.
I don't see that restriction. Anyone upgrading from before PG15 would
apply the transform. Just because we introduce a transform in PG15
doesn't mean we can't apply that transform in later releases as well,
to allow say PG14 -> PG16.
--
Simon Riggshttp://www.EnterpriseDB.com/
all required software is delivered in one shot, with fast
upgrade
2. As each table is VACUUMed, we confirm/clean/groom data blocks so
each table is individually confirmed as being ready. The pace that
this happens at is under user control.
3. When all tables have been prepared, then restart to allow xid64 format usage
--
Simon Riggshttp://www.EnterpriseDB.com/
and I will review with you as you go.
--
Simon Riggshttp://www.EnterpriseDB.com/
fects.
Tested using the attached test, so seems to work correctly.
On review of docs, no additions or changes required.
Perhaps add something to README? If so, minor doc patch attached.
Otherwise, this sub-patch is READY FOR COMMITTER.
--
Simon Riggshttp://www.Ent
uot;a.b.c.d"
>
> and of course many of the paths will often have JSONB documents as
> values, not simple scalar values. I wonder if we should limit the depth
> somehow, and maybe build stats only for scalar values.
The user interface for designing filters sounds hard, so I'd hope we
can ignore that for now.
--
Simon Riggshttp://www.EnterpriseDB.com/
ten in *some* common format, and the current heap
format currently works, so de facto it is the format we should use.
Right now, TAMs have to reformat back into this same format, so it is
the way the APIs work. Put it another way: I don't see any other
format that makes sense to use, now, but that could change in the
future.
So I'm signing up as a reviewer and we'll see if this is good to go.
--
Simon Riggshttp://www.EnterpriseDB.com/
sible behavior.
Please explain the various new states that pages can be in and what
the effects are,
My understanding is this would be backwards compatible, so we can
upgrade to it. Please confirm.
Thanks
--
Simon Riggshttp://www.EnterpriseDB.com/
more
pointers in a table
* We want to avoid putting the data length into the toast pointer, so
we can allow the toasted data to be expanded without rewriting
everything (to avoid O(N^2) cost)
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 22 Dec 2021 at 11:35, Simon Riggs wrote:
>
> On Mon, 15 Nov 2021 at 22:45, Alvaro Herrera wrote:
> >
> > On 2021-Nov-15, Alvaro Herrera wrote:
> >
> > > Thanks everyone for the feedback. I attach a version with the fixes
> > > that were sub
ALID));
>
> AFAICS, this assertion condition is constant-true,
> because TM_WouldBlock is a nonzero constant. Perhaps you meant
>
>Assert(result == TM_WouldBlock || !(tuple->t_data->t_infomask &
> HEAP_XMAX_INVALID));
Yes, I think that's what I meant.
--
Simon Riggshttp://www.EnterpriseDB.com/
me problem cases would help us decide either way.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 27 Oct 2021 at 15:58, Simon Riggs wrote:
> The poor performance is traced to the planner cost estimates for
> recursive queries. Specifically, the cost of the recursive arm of the
> query is evaluated based upon both of these hardcoded assumptions:
>
> 1. The recursion w
On Wed, 29 Dec 2021 at 03:30, Thomas Munro wrote:
>
> On Fri, Dec 10, 2021 at 1:43 AM Simon Riggs
> wrote:
> > "Applications using this level must be prepared to retry transactions
> > due to serialization failures."
> > ...
> > "When an applicat
lare.
Could we allow a user-defined auto_retry parameter?
We don't mention that a transaction might just repeatedly fail either.
Anyway, know y'all would have some opinions on this. Happy to document
whatever we agree.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 3 Dec 2021 at 06:27, Dilip Kumar wrote:
>
> On Tue, Nov 30, 2021 at 5:49 PM Simon Riggs
> wrote:
>
> > transam.c uses a single item cache to prevent thrashing from repeated
> > lookups, which reduces problems with shared access to SLRUs.
> > multitrans
a little more
> than 64 subtransactions and all the system is stuck. Or will it affect only
> backend using more than 64 subtransactions?
That is the objective: to isolate the effect to only those that
overflow. It seems possible.
--
Simon Riggshttp://www.EnterpriseDB.com/
rray when nsubxids <
PGPROC_MAX_CACHED_SUBXIDS
so we need not consult pg_subtrans in that case, see step 4 of
TransactionIdIsInProgress()
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 1 Dec 2021 at 14:33, Bossart, Nathan wrote:
>
> On 11/12/21, 8:56 AM, "Simon Riggs" wrote:
> > The combination of these two statements in a transaction hits an
> > Assert in heapam.c at line 4770 on REL_14_STABLE
>
> I've been unable to reproduce t
SUBXIDS.
This would make subtrans much smaller and avoid one-entry-per-page
which is a major source of cacheing.
This would means some light changes in GetSnapshotData().
Let me know if that seems interesting also?
--
Simon Riggshttp://www.EnterpriseDB.com/
subtrans_single_item_cache.v1.patch
Description: Binary data
On Fri, 12 Nov 2021 at 17:39, Tomas Vondra
wrote:
> So +1 to just get this committed, as it is.
This is a real issue affecting Postgres users. Please commit this soon.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Mon, 15 Nov 2021 at 09:47, Daniel Gustafsson wrote:
>
> > On 19 Sep 2021, at 20:32, Simon Riggs wrote:
>
> > My preferred approach would be to do this "for free" in the table
> > access method, but we're a long way from this in terms of actual
> > imple
), but this code is different from the pgbench test.
--
Simon Riggshttp://www.EnterpriseDB.com/
skip_locked_assert.v1.patch
Description: Binary data
skip_locked_then_update_test.v1.patch
Description: Binary data
On Wed, 3 Nov 2021 at 22:07, Alexander Korotkov wrote:
>
> Hi!
>
> On Wed, Nov 3, 2021 at 8:51 PM Simon Riggs
> wrote:
> > It is however, an undocumented modularity violation. I think that is
> > acceptable because of the ProcArrayLock traffic, but needs to ha
;
> LWLockRelease(ProcArrayLock);
> }
So I agree with this fix.
It is however, an undocumented modularity violation. I think that is
acceptable because of the ProcArrayLock traffic, but needs to have a
comment to explain this at the call to
ExpireOldKnownAssignedTransactionIds() i.e. " and potentially reset
lastOverflowedXid", as well as a comment on the
ExpireOldKnownAssignedTransactionIds() function.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 3 Nov 2021 at 13:28, Daniel Gustafsson wrote:
>
> > On 30 Jun 2021, at 11:59, Simon Riggs wrote:
>
> > For PITR, getRecordTimestamp() did not include all record types that
> > contain times.
> > Add handling for checkpoints, end of recovery and p
is to set
enable_seqscan = off, which helps about 20%, but may have other
consequences. Two is to set work_mem = 512MB, so that the poor plan
(hash) works as fast as possible, but that is far from optimal either.
Getting the right plan is x20 faster than either of those
alternatives.
--
Simon Riggs
On Thu, 14 Oct 2021 at 16:09, Peter Geoghegan wrote:
>
> On Thu, Oct 14, 2021 at 12:48 AM Simon Riggs
> wrote:
> > The hash index tuples are 20-bytes each. If that were rounded up to
> > 8-byte alignment, then that would be 24 bytes.
> >
> > Using pageinspect
On Wed, 13 Oct 2021 at 20:16, Peter Geoghegan wrote:
>
> On Wed, Oct 13, 2021 at 3:44 AM Simon Riggs
> wrote:
> > > IMO it'd be nice to show some numbers to support the claims that storing
> > > the extra hashes and/or 8B hashes is not worth it ...
> >
>
f there are some minor
> > sub-optimal aspects of using hash indexes, then btree was already the
> > default and a great choice for many cases.
> >
>
> But we can't select arbitrary column order, because the first column is
> used to select the bucket. Which means it's also about what columns are
> used by the queries. If the query is not using the first column, it
> can't use the index.
Neither approach works in that case, so it is moot. i.e. you cannot
use a first-column hash, nor an all-column hash.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 5 Oct 2021 at 12:24, Dilip Kumar wrote:
>
> On Tue, Oct 5, 2021 at 4:08 PM Simon Riggs
> wrote:
> >
> > On Mon, 27 Sept 2021 at 06:52, Amit Kapila wrote:
> > >
> > > On Thu, Sep 23, 2021 at 11:11 AM Dilip Kumar
> > > wrote:
> > &g
we would expect the
contention to be less than we would get on a monotonically increasing
btree.
So I don't now see any problem from holding the buffer lwlock on the
bucket while we do multi-buffer operations.
--
Simon Riggshttp://www.EnterpriseDB.com/
om
points out. It also needs fine tuning to make the all-column approach
beneficial for the additional cases without losing against what the
"first column" approach gives.
I did consider both approaches and after this discussion I am still in
favour of committing the very simple "first column" approach to
multi-col hash indexes now.
--
Simon Riggshttp://www.EnterpriseDB.com/
mplex it is.
At very least I will add a longer comment patch to mention this for the future.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 1 Oct 2021 at 15:20, Jaime Casanova
wrote:
> This has been stalled since July, and based on Peter's comment i feel we
> should mark this as RwF. Which i'm doing now.
>
> Please feel free to resubmit for Next Commitfest.
Agreed, thank you Jaime.
--
Simon Riggs
ion
--
Simon Riggshttp://www.EnterpriseDB.com/
the
syntax in there, this was the direction I was thinking.
After waiting a day since I wrote the above, I think we should go with
(2) as Corey suggests, at least for now, and we can always add (3)
later.
--
Simon Riggshttp://www.EnterpriseDB.com/
llow us to switch
between languages and have default languages for specific users or
databases.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 10 Sept 2021 at 19:30, Jaime Casanova
wrote:
>
> On Tue, Aug 10, 2021 at 01:20:14PM +0100, Simon Riggs wrote:
> > On Wed, 14 Jul 2021 at 12:48, vignesh C wrote:
> >
> > > The patch does not apply on Head anymore, could you rebase and post a
> >
d types, so is suitable and extensible.
We could add a new field type of 'm' to represent a message sent from
middleware to the client.
--
Simon Riggshttp://www.EnterpriseDB.com/
The question is how does a client communicate with middleware?
The message that would be sent would relate to the features of the
middleware, while being agnostic as to the client driver.
--
Simon Riggshttp://www.EnterpriseDB.com/
eneralized interface that can be used for a great many things.
* Failover managers
* Load Balancers
* Routing agents
* Things I haven't thought of yet, but others may have
etc..
We are currently limited by the messages we can send efficiently.
--
Simon Riggshttp://www.EnterpriseDB.com/
play nicely with Logical Decoding is another can of
> worms needing to be solved, but it is a start to becoming "Cloud
> Native" :)
Good ideas!
--
Simon Riggshttp://www.EnterpriseDB.com/
over to replica x.x.x.x, please follow"
That sounds like a server->middleware message and existing mechanisms
might work for that already.
--
Simon Riggshttp://www.EnterpriseDB.com/
call to utilise this.
In summary: the patch is easy, the point is we need agreement to allow
and encourage interoperation between clients and middleware.
Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Sat, 14 Aug 2021 at 09:03, Peter Eisentraut
wrote:
>
> On 13.08.21 19:07, Tom Lane wrote:
> > "David G. Johnston" writes:
> >> On Fri, Aug 13, 2021 at 9:28 AM Simon Riggs
> >> wrote:
> >>> The only hope is to eventually change the d
know and my patch didn't help them
either. The only hope is to eventually change the default, so probably
the best thing is to apply pressure via the SQL Std process.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, 12 Aug 2021 at 20:07, Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Thu, Aug 12, 2021 at 07:24:58PM +0100, Simon Riggs wrote:
> >> I heard the moan about "Why doesn't TIMESTAMP mean TIMESTAMP WITH TIME
> >> ZONE" again today,
LTER TABLE command to make switching from WITHOUT to WITH
TIME ZONE easy, so it is clearly an important thing to solve.
So add a parameter called
default_timestamp_with_timezone = off (default) | on
Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
default_timestamp_with_t
e... then we have a PG14 bug.
If we do want to see this in WAL, both xl_heap_vacuum and
xl_heap_prune lend themselves to just adding one more OffsetNumber
onto the existing array, to represent the highest offset after
truncation. So we don't need to change the WAL format.
--
Simon Riggshttp://www.EnterpriseDB.com/
trict;
\d abc
Table "public.abc"
Column | Type | Collation | Nullable | Default
+-+---+--+-
a | integer | | not null |
b | integer | | not null |
Noting that all constraints have been remov
On Wed, 4 Aug 2021 at 01:43, Peter Geoghegan wrote:
>
> On Mon, Aug 2, 2021 at 11:57 PM Simon Riggs
> wrote:
> > 1. Allow same thing as PageTruncateLinePointerArray() during HOT cleanup
> > That is going to have a clear benefit for HOT workloads, which by
> > their na
On Thu, 15 Jul 2021 at 07:47, Simon Riggs wrote:
>
> On Sat, Jul 10, 2021 at 2:50 PM John Naylor
> wrote:
> > On Thu, Apr 22, 2021 at 8:01 AM Simon Riggs
> > wrote:
> > >
> > > 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> >
multiple
additional FPIs in WAL. I don't call that a future optimization, I
call that essential additional work.
+1 on committing the first part of the patch, -1 on the second. I
suggest you split the patch and investigate the second part further.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 3 Aug 2021 at 17:13, Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Tue, Aug 3, 2021 at 04:53:40PM +0100, Simon Riggs wrote:
> >> There are 273 patches in the queue for the Sept Commitfest already, so
> >> it seems clear the queue is
additional coordination to actively clear
down this problem? I won't attempt to come up with ideas to do this,
but others may wish to suggest ways that avoid Committer burn-out?
I will be happy to volunteer to be part of an organized approach that
spreads out the work.
Thanks
--
Simon Riggs
t from the patch and consider that
as a separate issue, or close this.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Mon, 26 Jul 2021 at 17:49, Tom Lane wrote:
>
> I wrote:
> > Simon Riggs writes:
> >> Surely we need a test to exercise this works? Otherwise ready...
>
> > There are lots of places in the core regression tests where we'd have
> > used a temp table,
myTempNamespace. Basically try to make that alias
> > a bit less leaky.
>
> +1, let's replace it by "pg_temp" -- did the same in that attached 0001 patch.
Sounds like a good change.
Surely we need a test to exercise this works? Otherwise ready...
--
Simon Riggshttp://www.EnterpriseDB.com/
d uniqueness checks. The latter
is because there are parse analysis changes needed to undo the
assumption that only btrees support uniqueness, but nothing there
looks like an issue.
Thanks for your input, have a good weekend.
--
Simon Riggshttp://www.EnterpriseDB.com/
hash_
ta, if it exists
* pg_waldump --user=USERNAME as a filter on username
to demonstrate the use of this
--
Simon Riggshttp://www.EnterpriseDB.com/
s more than 2 long (bucket plus overflow), so it seems
like mostly wasted effort at this point.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, Jul 20, 2021 at 1:00 PM Amit Kapila wrote:
>
> On Thu, Jul 15, 2021 at 10:11 PM Simon Riggs
> wrote:
> >
> > 2. Unique Hash Indexes have been summarized here:
> > https://www.postgresql.org/message-id/CAA4eK1KATC1TA5bR5eobYQVO3RWsnH6djNpk3P376em4V8MuUA%40ma
I have other performance tuning ideas, but they can wait.
Anyway, that's what I think at present. Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 14 Jul 2021 at 17:22, vignesh C wrote:
>
> On Thu, Apr 8, 2021 at 11:40 PM Simon Riggs wrote:
> >
> > On Thu, 8 Apr 2021 at 18:15, Alvaro Herrera wrote:
> > >
> > > On 2021-Apr-08, Simon Riggs wrote:
> > >
> > > > On Thu, 8 Apr
On Sat, Jul 10, 2021 at 2:50 PM John Naylor
wrote:
> On Thu, Apr 22, 2021 at 8:01 AM Simon Riggs
> wrote:
> >
> > 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> > level for CHECK constraints when allowing them to be NOT VALID.
> >
> >
On Fri, Jul 2, 2021 at 12:50 AM Bruce Momjian wrote:
>
> On Thu, Jul 1, 2021 at 03:13:30PM +0100, Simon Riggs wrote:
> > On Wed, Jun 30, 2021 at 11:20 PM Bruce Momjian wrote:
> > > > * "row expiration" is a term not currently used in PG docs, so we
> >
On Tue, Jul 6, 2021 at 4:21 AM Amit Kapila wrote:
>
> On Fri, Jul 2, 2021 at 8:29 PM Simon Riggs
> wrote:
> >
> > On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer
> > wrote:
> > >
> >
> > > If you don't think the sorts of use cases I presented a
On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer
wrote:
>
> On Fri, 2 Jul 2021 at 00:19, Simon Riggs wrote:
>
>>
>> > So yeah. I think it'd be better to log the info you want at start-of-txn
>> > unless there's a compelling reason not so, and I don't see one yet.
for this because it
will slow down applications and it won't get turned on as often.
Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, Jun 24, 2021 at 7:15 PM Fabien COELHO wrote:
>
>
> Hello Simon,
>
> Indeed.
>
> There is already a "ready" patch in the queue, see:
>
> https://commitfest.postgresql.org/33/3034/
Ah, my bad. I withdraw this patch, apologies Tatsuo-san.
On Fri, Jun 25, 2021 at 4:44 PM Peter Geoghegan wrote:
>
> On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs
> wrote:
> > Seems a little bizarre to have _bt_check_unique() call back into the
> > heap block we literally just unpinned.
>
> I suppose it is a little bizarre.
On Wed, Jun 30, 2021 at 11:20 PM Bruce Momjian wrote:
>
> On Tue, Jun 29, 2021 at 07:36:47PM +0100, Simon Riggs wrote:
> > Perhaps we should also add this text from the commit message to ensure
> > the importance is understood:
> > "This is extremely useful
; includes docs.
--
Simon Riggshttp://www.EnterpriseDB.com/
pitr_enhance_getRecordTimestamp.v1.patch
Description: Binary data
PITR of Abort Prepared generates the wrong log message.
Fix attached
--
Simon Riggshttp://www.EnterpriseDB.com/
pitr_recoveryStopsBefore_AbortPrepared.v1.patch
Description: Binary data
On Fri, Jun 25, 2021 at 2:56 AM Bruce Momjian wrote:
>
> On Wed, Jun 23, 2021 at 07:45:53AM -0700, Peter Geoghegan wrote:
> > On Wed, Jun 23, 2021 at 5:50 AM Simon Riggs
> > wrote:
> > > I just noticed that these commits are missing, yet are very i
On Fri, Jun 25, 2021 at 4:17 AM Amit Kapila wrote:
>
> On Fri, Jun 25, 2021 at 1:29 AM Bruce Momjian wrote:
> >
> > aOn Wed, Jun 23, 2021 at 12:56:51PM +0100, Simon Riggs wrote:
> > > On Wed, Jun 23, 2021 at 5:12 AM Amit Kapila
> > > wrote:
> > > &g
On Fri, Jun 25, 2021 at 2:34 AM Peter Geoghegan wrote:
>
> On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs
> wrote:
> > This case occurs when we are doing non-HOT UPDATEs. That command is
> > searched, so the scan will already have touched the heap and almost
> > certai
nce individual smgr files.
If that requires that we add a new non-default option, no problem.
Most people will want to use that option, AFAICS.
--
Simon Riggshttp://www.EnterpriseDB.com/
pgbench -i should use COPY FREEZE, patch attached.
--
Simon Riggshttp://www.EnterpriseDB.com/
pgbench_copy_freeze.v1.patch
Description: Binary data
to add support for FREEZE into pg_restore.
Thanks
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, Jun 23, 2021 at 5:42 PM Peter Geoghegan wrote:
>
> On Wed, Jun 23, 2021 at 9:31 AM Simon Riggs
> wrote:
> > You're right that skipping the check might also skip killing a prior
> > row version, but it doesn't prevent later scans from killing them, so
> > the
On Wed, Jun 23, 2021 at 5:17 PM Peter Geoghegan wrote:
>
> On Mon, Jun 21, 2021 at 5:31 AM Simon Riggs
> wrote:
> > Seems like we can skip the uniqueness check if indexUnchanged, which
> > will speed up non-HOT UPDATEs on tables with B-Trees.
>
> I thought about d
yet are very important
new features:
d9d076222f5b94a8
f9900df5f9
c98763bf51bf
These are important enough to be major features of PG14.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, Jun 23, 2021 at 5:12 AM Amit Kapila wrote:
>
> On Tue, Jun 22, 2021 at 2:31 PM Simon Riggs
> wrote:
> >
> > I attach both clean and compare versions.
> >
>
> Do we want to hold this work for PG15 or commit in PG14 and backpatch
> it till v10 where we
201 - 300 of 699 matches
Mail list logo
