On Mon, 28 Nov 2022 at 18:53, Alvaro Herrera wrote:
>
> On 2022-Nov-28, Simon Riggs wrote:
>
> > A narrative description of the issue follows:
> > session1 - requests multiple nested subtransactions like this:
> > BEGIN; ...
> > SAVEPOINT subxid1; ...
> > S
On Mon, 28 Nov 2022 at 17:38, Robert Haas wrote:
>
> On Mon, Nov 28, 2022 at 10:28 AM Simon Riggs
> wrote:
> > So we have these options
> >
> > 1. Removing the XactLockTableDelete() call in CommitSubTransaction().
> > That releases lock waiters earlier than exp
nuously busy duty cycle and most of
them not in the cloud.
If we guess that we save 10W when idle, then that saves some proportion of a GW.
It's not a huge contribution to the effort, but if by doing this we
inspire others to do the same, we may yet make a difference.
--
Simon Riggshttp://www.EnterpriseDB.com/
reuse the final state of other
modules' tests to test cleanup, or at least integrate a custodian test
into each module.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Sun, 20 Nov 2022 at 20:00, Simon Riggs wrote:
>
> On Thu, 24 Mar 2022 at 16:21, Robert Haas wrote:
> >
> > On Thu, Mar 24, 2022 at 12:02 PM Simon Riggs
>
> > > What changes will be acceptable for bgwriter, walwriter and logical
> > > worker?
> >
&
On Thu, 17 Nov 2022 at 17:29, Simon Riggs wrote:
> (yes, the last line shows x10 performance patched, that is not a typo)
New version of patch, now just a one-line patch!
Results show it's still a good win for XidInMVCCSnapshot().
--
Simon Riggshttp://www.Enterpri
avior, if we do.
The really big issue is the loss of performance we get from having
subtrans point only to its immediate parent, which makes
XidInMVCCSnapshot() go really slow in the presence of lots of
subtransactions. So ignoring the issue on this thread will open the
door for the optimizati
On Wed, 30 Nov 2022 at 03:56, Nathan Bossart wrote:
>
> On Tue, Nov 29, 2022 at 12:02:44PM +, Simon Riggs wrote:
> > The last important point for me is tests, in src/test/modules
> > probably. It might be possible to reuse the final state of other
> > modules'
On Wed, 30 Nov 2022 at 03:50, Thomas Munro wrote:
>
> On Wed, Nov 30, 2022 at 1:32 AM Simon Riggs
> wrote:
> > Re-attaching patch for bgwriter and walwriter, so it is clear this is
> > not yet committed.
>
> I'm just curious, and not suggesting that 60s wakeups a
and pushed.
That is a complete patch from multiple angles; very happy here.
Thanks for a great job.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 30 Nov 2022 at 01:51, Bruce Momjian wrote:
> Thanks to Simon for getting this important
> information in our docs, and for the valuable feedback from others that
> made this even better.
And thanks to you for pulling that all together Bruce.
--
Simon Riggs
The docs don't explicitly mention the reduced lock level for this subcommand.
--
Simon Riggshttp://www.EnterpriseDB.com/
alter_table_validate_lock_level.patch
Description: Binary data
897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
level for CHECK constraints when allowing them to be NOT VALID.
This is simple and safe, since check constraints are not used in
planning until validated.
--
Simon Riggshttp://www.EnterpriseDB.com
On Fri, 16 Sept 2022 at 13:20, Simon Riggs wrote:
>
> Thanks for the review.
>
> v10 attached
v11 attached, corrected for recent commit
14ff44f80c09718d43d853363941457f5468cc03.
--
Simon Riggshttp://www.EnterpriseDB.com/
002_minimize_calls_to_SubTransSetPare
where
> this helps significantly are at all mainstream, so I'm kind of leaning
> to "patch HEAD only".
It looks fine to eventually backpatch, since StandbyReleaseLockTree()
was optimized to only be called when the transaction had actually done
some AccessExclusiveLocks.
So the performance loss is minor and isolated to the users of such
locks, so I see no problems with it.
--
Simon Riggshttp://www.EnterpriseDB.com/
ther user visible behavior". A complex example is given to explain,
using the terminology established in the main patch.
--
Simon Riggshttp://www.EnterpriseDB.com/
xact.patch-on-patch
Description: Binary data
doc-release-savepoint.v1.patch
Description: Binary data
xids are recorded in
> > +the pg_multixact directory.
> > +
>
> Hmm, ok.
>
> > +
> > +The parent xid of each subxid is recorded in the
> > +pg_subtrans directory. No entry is made for
> > +top-level xids since they do not have a parent, nor is an entry made
> > +for read-only subtransactions.
> > +
>
> Maybe say "the immediate parent xid of each ...", or is it too obvious?
+1 to all of those suggestions
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 14 Oct 2022 at 08:55, Simon Riggs wrote:
> In related changes, I've also done some major rewording of the RELEASE
> SAVEPOINT command, since it was incorrectly described as having "no
> other user visible behavior". A complex example is given to explain,
actions created by the named savepoint,
these will also be subcommitted.
The point is that savepoints create subtransactions, but they are not
the only way to create them, so we cannot equate savepoint and
subtransaction completely.
--
Simon Riggshttp://www.EnterpriseDB.com/
.
When in a xact block, we do not set PROC_IN_VACUUM,
nor update datfrozenxid.
Tests, docs.
--
Simon Riggshttp://www.EnterpriseDB.com/
single_table_vacuum.v1.patch
Description: Binary data
n purpose of these features is hopefully clear from these notes.
001 and 003 are fairly small patches, 002 is longer.
Comments please
--
Simon Riggshttp://www.EnterpriseDB.com/
001_psql_parse_only.v1.patch
Description: Binary data
002_nested_xacts.v7.patch
Description: Binary da
On Thu, 27 Oct 2022 at 10:31, Simon Riggs wrote:
> Tests, docs.
The patch tester says that a pg_upgrade test is failing on Windows,
but works for me.
t/002_pg_upgrade.pl .. ok
Anybody shed any light on that, much appreciated.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, 27 Oct 2022 at 12:09, Simon Riggs wrote:
> Comments please
Update from patch tester results.
--
Simon Riggshttp://www.EnterpriseDB.com/
002_nested_xacts.v7.patch
Description: Binary data
001_psql_parse_only.v1.patch
Description: Binary d
On Fri, 28 Oct 2022 at 07:54, Erik Rijkers wrote:
>
> Op 27-10-2022 om 18:35 schreef Simon Riggs:
> > On Thu, 27 Oct 2022 at 12:09, Simon Riggs
> > wrote:
> >
> >> Comments please
> >
> > Update from patch tester results.
> >
>
> > [
On Fri, 28 Oct 2022 at 10:33, Simon Riggs wrote:
> Thanks for the feedback, I will make all of those corrections in the
> next version.
New version attached. I've rolled 002-004 into one patch, but can
split again as needed.
--
Simon Riggshttp://www.Enter
the GUC.
So its not a problem, but thanks for checking.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Mon, 31 Oct 2022 at 12:22, Dilip Kumar wrote:
>
> On Mon, Oct 31, 2022 at 5:03 PM Dilip Kumar wrote:
> >
> > On Mon, Oct 31, 2022 at 4:23 PM Dilip Kumar wrote:
> > >
> > > On Sun, Oct 30, 2022 at 11:32 PM Simon Riggs
> > > wrote:
> > &g
e no volunteers, maybe it is because the job of CFM is too
big now and needs to be split.
I can offer to be co-CFM, and think I can offer to be CFM for about
100 patches, but I don't have the time to do the whole thing myself.
--
Simon Riggshttp://www.EnterpriseDB.com/
eral psql scripting.
...since if we used this in a script, it would be used like this, I think...
SELECT $1, $2
\gp 'foo' 'bar'
\gp 'bar' 'baz'
...
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 1 Nov 2022 at 20:48, Peter Eisentraut
wrote:
>
> On 01.11.22 10:10, Simon Riggs wrote:
> > On Fri, 28 Oct 2022 at 07:53, Peter Eisentraut
> > wrote:
> >>
> >> This adds a new psql command \gp that works like \g (or semicolon) but
> >> uses
On Thu, 27 Oct 2022 at 21:07, Justin Pryzby wrote:
>
> On Thu, Oct 27, 2022 at 10:31:31AM +0100, Simon Riggs wrote:
> > Allows both ANALYZE and vacuum of toast tables, but not VACUUM FULL.
>
> Maybe I misunderstood what you meant: you said "not VACUUM FULL", but
&
uot; an ERROR with
> > ERRCODE_WRONG_OBJECT_TYPE
> > is reported). Then either the desired code should be passed to
> > partitioned_table_reloptions() or similar checks and ereport calls
> > should be
> > placed in two different places. I'm not sure whether it is a good idea to
> > change the code in one of these ways just to change the error code.
> >
> > Best regards,
> > Karina Litskevich
> > Postgres Professional: http://postgrespro.com/
>
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 2 Nov 2022 at 03:52, Dilip Kumar wrote:
>
> On Mon, Oct 31, 2022 at 6:54 PM Simon Riggs
> wrote:
> >
> > > > What is the behavior if "nested_transactions" value is changed within
> > > > a transaction execution, suppose the value was on a
On Tue, 1 Nov 2022 at 23:56, Simon Riggs wrote:
> > I haven't checked the rest of the patch, but +1 for allowing VACUUM FULL
> > within a user txn.
>
> My intention was to prevent that. I am certainly quite uneasy about
> changing anything related to CLUSTER/VF, since t
transaction block the vacuum scan can
> +hold back the xmin horizon and does not update the database datfrozenxid,
> +as a result this usage is not useful for database maintenance, but is
> provided
> +to allow vacuuming in special circumstances, such as temp
ecoding SQL Interface
> > System Catalogs Related to Logical Decoding
> >
>
> I think this is worth considering but we might want to discuss this as
> a separate change/patch.
Makes sense.
Thanks
--
Simon Riggshttp://www.EnterpriseDB.com/
Seems like we can skip the uniqueness check if indexUnchanged, which
will speed up non-HOT UPDATEs on tables with B-Trees.
Passes tests.
Comments?
--
Simon Riggshttp://www.EnterpriseDB.com/
skip_nonHOT_btree_unique_check.v1.patch
Description: Binary data
New chapter for Hash Indexes, designed to help users understand how
they work and when to use them.
Mostly newly written, but a few paras lifted from README when they were helpful.
--
Simon Riggshttp://www.EnterpriseDB.com/
doc_hash_index.v1.patch
Description: Binary data
On Thu, Mar 18, 2021 at 6:20 AM Craig Ringer
wrote:
>
> On Mon, 15 Mar 2021 at 21:01, David Steele wrote:
>>
>> On 11/18/20 5:23 AM, Simon Riggs wrote:
>> > On Wed, 18 Nov 2020 at 06:42, Craig Ringer
>> > wrote:
>> >>
>>
On Wed, Jan 20, 2021 at 3:53 PM James Coleman wrote:
>
> On Wed, Jan 20, 2021 at 9:58 AM Simon Riggs wrote:
> >
> > On Wed, 20 Jan 2021 at 14:21, James Coleman wrote:
> >
> > > An alternative approach that occurred to me while typing this reply: a
> > &g
On Tue, Jun 22, 2021 at 7:15 AM Amit Kapila wrote:
>
> On Mon, Jun 21, 2021 at 6:38 PM Simon Riggs
> wrote:
> >
> > New chapter for Hash Indexes, designed to help users understand how
> > they work and when to use them.
> >
> > Mostly newly written, but a
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
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: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 doin
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
> &
add support for FREEZE into pg_restore.
Thanks
--
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
e, just like it would be
if we allowed people to reference 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/
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
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: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
PITR of Abort Prepared generates the wrong log message.
Fix attached
--
Simon Riggshttp://www.EnterpriseDB.com/
pitr_recoveryStopsBefore_AbortPrepared.v1.patch
Description: Binary data
; includes docs.
--
Simon Riggshttp://www.EnterpriseDB.com/
pitr_enhance_getRecordTimestamp.v1.patch
Description: Binary data
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 in cas
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.
&g
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.
x27;t really want to add an extra record just for this because it
will slow down applications and it won't get turned on as often.
Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
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'
On Sat, 30 Apr 2022 at 12:12, Amit Kapila wrote:
>
> On Tue, Apr 19, 2022 at 3:05 AM Simon Riggs
> wrote:
> >
> > Hash index pages are stored in sorted order, but we don't prepare the
> > data correctly.
> >
> > We sort the data as the first step of a
skips catalog tables,
as a way of avoiding the known deadlocks. Patch also adds a test.
--
Simon Riggshttp://www.EnterpriseDB.com/
reindex_not_require_database_name.v2.patch
Description: Binary data
d on the buckets they belong to. Below masks
> * are used in _hash_hashkey2bucket to determine the bucket of given hash
> * key.
> */
Addressed in new patch, v2.
On Wed, 4 May 2022 at 11:27, Amit Kapila wrote:
>
> So, we should go with this unless someone else sees any flaw h
On Tue, 10 May 2022 at 14:47, Ashutosh Bapat
wrote:
>
> On Tue, May 10, 2022 at 2:43 PM Simon Riggs
> wrote:
> >
> > A minor issue, and patch.
> >
> > REINDEX DATABASE currently requires you to write REINDEX DATABASE
> > dbname, which makes this
nds up being
limited in scope. So I think we also need an rm_checkpoint() call -
which would be a no-op for existing rmgrs.
[PATCH: rmgr_003.v1.patch]
The above turns out to be fairly simple, but extends the API to
something truly flexible.
Please let me know what you think?
--
Simon Riggs
ke REINDEX DATABASE the same as REINDEX (SKIP_SYSTEM_CATALOGS
OFF) DATABASE then it is just dangerous and annoying, i.e. a POLA
violation.
The point of this was a usability improvement, not just new syntax.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, 12 May 2022 at 04:40, Andres Freund wrote:
>
> On 2022-05-11 09:39:48 -0700, Jeff Davis wrote:
> > On Wed, 2022-05-11 at 15:24 +0100, Simon Riggs wrote:
> > > [PATCH: rmgr_001.v1.patch]
> > >
> > > [PATCH: rmgr_002.v1.patch]
> >
> > T
On Fri, 13 May 2022 at 05:13, Jeff Davis wrote:
>
> On Thu, 2022-05-12 at 22:26 +0100, Simon Riggs wrote:
> > I see multiple uses for the rm_checkpoint() point proposed and I've
> > been asked multiple times for a checkpoint hook.
>
> Can you elaborate and/or link
On Fri, 13 May 2022 at 00:42, Andres Freund wrote:
>
> On 2022-05-12 22:26:51 +0100, Simon Riggs wrote:
> > On Thu, 12 May 2022 at 04:40, Andres Freund wrote:
> > > I'm not happy with the idea of random code being executed in the middle of
> > > CheckPointG
simple, but that's exactly what users do anyway,
so it is not too bad.
Tests, docs included.
--
Simon Riggshttp://www.EnterpriseDB.com/
create_stats_opt_name.v3.patch
Description: Binary data
o avoid long running tasks is
good, if that is possible. That can be done better over time. This
point does not block the higher level goal of better availability
asap, so I support Nathan's overall proposals.
--
Simon Riggshttp://www.EnterpriseDB.com/
avepoint name duplicated earlier
defined savepoints then those earlier savepoints can only be released if
multiple ROLLBACK TO SAVEPOINT commands are issued with the same
name, as shown in the following example."
Also, I would just call the savepoint "s" in the example, to declutter it.
--
Simon Riggshttp://www.EnterpriseDB.com/
l this feature does is allow you to implement things in a lazy way
that causes a loss of availability for users. I don't think that is of
benefit to PostgreSQL users, so -1 from me, on this patch (only),
sorry about that.
--
Simon Riggshttp://www.EnterpriseDB.com/
these things, so
we can make sure the design and code allows for those future
enhancements.
i.e. how will we do ALTER TABLE ... UPGRADE DICTIONARY without causing
a table rewrite?
* Does the order of entries in the dictionary allow us to express a
priority? i.e. to allow Huffman coding.
Thanks for your efforts - this is a very important patch.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, 23 Jun 2022 at 14:46, Robert Haas wrote:
>
> On Thu, Jun 23, 2022 at 7:58 AM Simon Riggs
> wrote:
> > Having a central cleanup process makes a lot of sense. There is a long
> > list of potential tasks for such a process. My understanding is that
> > autovacu
On Thu, 23 Jun 2022 at 18:45, Nathan Bossart wrote:
>
> Thanks for chiming in.
>
> On Thu, Jun 23, 2022 at 04:19:45PM +0100, Simon Riggs wrote:
> > I don't understand why you need this patch at all.
> >
> > Since you have automation, you can use that lay
On Thu, 23 Jun 2022 at 18:15, Nathan Bossart wrote:
> I'm grateful for the discussion in this thread so far, but I'm not seeing a
> clear path forward.
+1 to add the new auxiliary process.
--
Simon Riggshttp://www.EnterpriseDB.com/
() calls? That's not new with this
> patch, though, it could happen with the single-item cache in transam.c, too.
Yes, as a separate patch only in PG15+, imho.
--
Simon Riggshttp://www.EnterpriseDB.com/
alogs, doing the same
> thing as REINDEX DATABASE today?
A key point is that REINDEX SYSTEM has problems, so should be avoided.
Hence, including both database and system together in a new command
would not be great idea, at this time.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 28 Jun 2022 at 08:29, Simon Riggs wrote:
>
> On Thu, 2 Jun 2022 at 01:02, Michael Paquier wrote:
> >
> > On Tue, May 31, 2022 at 02:30:32PM +0200, Alvaro Herrera wrote:
> > > I was thinking the opposite: REINDEX DATABASE with or without a database
> >
ple 64-bit RelFileNumber, without
restriction, and probably some spare bytes on the ForkNumber, if we
needed them later.
--
Simon Riggshttp://www.EnterpriseDB.com/
he nicely.
For convenience, I imagine that the mapping could be included in WAL
in or near the checkpoint record, to ensure that the mapping was
available in all backups.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 29 Jun 2022 at 05:35, Michael Paquier wrote:
>
> On Tue, Jun 28, 2022 at 11:02:25AM +0100, Simon Riggs wrote:
> > Attached patch is tested, documented and imho ready to be committed,
> > so I will mark it so in CFapp.
Thanks for the review Michael.
> The behavi
On Thu, 30 Jun 2022 at 03:43, Thomas Munro wrote:
>
> On Thu, Jun 30, 2022 at 12:41 AM Simon Riggs
> wrote:
> > The reason to mention this now is that it would give more space than
> > 56bit limit being suggested here.
>
> Isn't 2^56 enough, though?
For m
On Wed, 6 Jul 2022 at 19:35, Matthias van de Meent
wrote:
>
> On Sun, 15 May 2022 at 14:20, Simon Riggs
> wrote:
> >
> > Currently, CREATE STATS requires you to think of a name for each stats
> > object, which is fairly painful, so users would prefer an
>
On Thu, 7 Jul 2022 at 11:58, Matthias van de Meent
wrote:
>
> On Thu, 7 Jul 2022 at 12:55, Simon Riggs wrote:
> > There are various other ways of doing this and, yes, we could refactor
> > other parts of the grammar to make this work. There is a specific
> > guideline abo
itfest.cputube.org/simon-riggs.html
Thanks for showing me that, it is very helpful.
> This patch has been marked as waiting for a review, however the CF bot
> is completely red:
Yes, it is failing, but so is current HEAD, with some kind of libpq
pipelining error.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 15 Jul 2022 at 09:12, Alvaro Herrera wrote:
>
> On 2022-Jul-15, Simon Riggs wrote:
>
> > On Fri, 15 Jul 2022 at 04:44, Michael Paquier wrote:
>
> > > This patch has been marked as waiting for a review, however the CF bot
> > > is completely red:
&
On Fri, 15 Jul 2022 at 12:15, Simon Riggs wrote:
>
> On Fri, 15 Jul 2022 at 09:12, Alvaro Herrera wrote:
> >
> > On 2022-Jul-15, Simon Riggs wrote:
> >
> > > On Fri, 15 Jul 2022 at 04:44, Michael Paquier wrote:
> >
> > > > This patch has been
t; get_database_name(), something that there is no need for as long as
> the routine is called once in ReindexMultipleTables().
OK, let me repost the new patch and see if CFbot likes that better.
This includes Michael's other requested changes for reindexdb.
--
Simon Riggs
d.
>
> Standard recommendation on macOS with SIP on is to always do "make
> install" before "make check".
Thanks, will investigate.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 15 Jul 2022 at 12:25, Simon Riggs wrote:
>
> On Mon, 4 Jul 2022 at 08:00, Michael Paquier wrote:
> >
> > On Sun, Jul 03, 2022 at 05:41:31PM -0400, Tom Lane wrote:
> > > This is marked as Ready for Committer, but that seems unduly
> > > optimistic.
&g
On Sun, 17 Jul 2022 at 07:19, Michael Paquier wrote:
>
> On Fri, Jul 15, 2022 at 06:21:22PM +0100, Simon Riggs wrote:
> > That's fixed it on the CFbot. Over to you, Michael. Thanks.
>
> Sure. I have looked over that, and this looks fine overall. I have
> made two chan
y all need to be checked. So before I do that, it seems
sensible to agree the approach.
(Obviously, there are hundreds of places where BTEqualStrategyNumber
is hardcoded, and this doesn't change that at all, in case that wasn't
clear).
Comments welcome on this still WI
On Thu, 21 Jul 2022 at 15:12, Dean Rasheed wrote:
>
> On Wed, 20 Jul 2022 at 12:01, Matthias van de Meent
> wrote:
> >
> > On Wed, 13 Jul 2022 at 08:07, Simon Riggs
> > wrote:
> > >
> > > > + *CREATE STATISTICS [ [IF NOT EXISTS]
On Fri, 22 Jul 2022 at 10:23, Matthias van de Meent
wrote:
>
> On Tue, 19 Jul 2022 at 18:56, Simon Riggs
> wrote:
> >
> > I'm preparing the way for a later patch that would allow unique hash
> > indexes to be primary keys. There are various parts to the problem.
es bloated.
+*/
+} FreeSpaceStrategy;
All we need is a simple heuristic to allow us to choose between
various strategies.
Your input is welcome! Please read the short patch.
--
Simon Riggshttp://www.EnterpriseDB.com/
freespace_strategy.v2.patch
Description: Binary data
On Tue, 26 Jul 2022 at 11:02, Dilip Kumar wrote:
>
> On Tue, Jul 26, 2022 at 3:04 PM Simon Riggs
> wrote:
> >
> > A long time ago, Tom Lane came up with the idea that when tables get
> > bloated, tables might be allowed to shrink down again in size
> > naturally
et's have a
democratic vote on moving this forwards:
+1 from me.
--
Simon Riggshttp://www.EnterpriseDB.com/
ion dictionary in the catalog prevent that
dictionary from being used within the toaster?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 27 Jul 2022 at 19:22, Tom Lane wrote:
>
> Simon Riggs writes:
> > [ hash_sort_by_hash.v2.patch ]
>
> The cfbot says this no longer applies --- probably sideswiped by
> Korotkov's sorting-related commits last night.
Thanks for the nudge. New version
Starting new thread with updated patch to avoid confusion, as
mentioned by David Steele on the original thread:
Original messageid: 20201118020418.GA13408@alvherre.pgsql
On Wed, 18 Nov 2020 at 02:04, Alvaro Herrera wrote:
> On 2020-Nov-17, Simon Riggs wrote:
>
> > As an additional
401 - 500 of 716 matches
Mail list logo
