y in read-only pgbench.
I don't have an M1 at hand. Could you do some profiling to identify
the source of such a huge difference.
--
Regards,
Alexander Korotkov
d be other options to do this even
better.
Links
1.
https://linux-concepts.blogspot.com/2018/05/spinlock-implementation-in-arm.html
--
Regards,
Alexander Korotkov
test.c
Description: Binary data
rg/message-id/4E1DE580.1090905%40enterprisedb.com
2.
https://www.postgresql.org/message-id/CAPpHfdvMvsw-NcE5bRS7R1BbvA4BxoDnVVjkXC5W0Czvy9LVrg%40mail.gmail.com
3.
https://www.postgresql.org/message-id/BF9B38A4-2BFF-46E8-BA87-A2D00A8047A6%40hintbits.com
------
Regards,
Alexander Korotkov
0001-Stopev
The name pg_waitlsn_no_wait() looks confusing. I've tried to see how
it's documented, but the patch doesn't contain documentation...
--
Regards,
Alexander Korotkov
On Mon, Nov 16, 2020 at 2:13 AM Jeff Janes wrote:
> On Sat, Nov 14, 2020 at 12:31 AM Alexander Korotkov
> wrote:
>> I went through and revised this patch. I made the documentation
>> statement less categorical. pg_trgm gist/gin indexes might have lower
>> performa
On Sat, Nov 14, 2020 at 8:26 PM Julien Rouhaud wrote:
> On Sat, Nov 14, 2020 at 7:58 PM Erik Rijkers wrote:
> >
> > On 2020-11-14 12:53, Julien Rouhaud wrote:
> > > On Sat, Nov 14, 2020 at 6:07 PM Alexander Korotkov
> > > >
> >
> > >Note th
RPa1up1Lzh_UQ%40mail.gmail.com
--
Regards,
Alexander Korotkov
Hi, Erik!
On Sat, Nov 14, 2020 at 11:37 AM Erik Rijkers wrote:
> On 2020-11-14 06:30, Alexander Korotkov wrote:
>
> > [v4-0001-Handle-equality...in-contrib-pg_trgm.patch (~]
> >
> > I'm going to push this if no objections.
> >
>
> About the sgml, in doc/sr
quite
dumb, it selects btree_gist index due to its lower size. So, this
part also looks good to me.
I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
v4-0001-Handle-equality-operator-in-contrib-pg_trgm.patch
Description: Binary data
gn bug in phrase
search. Fixing this would require some kind of readahead or multipass
processing, because we don't know how to process 'pg_class' in
advance.
Is this really a design bug existing in phrase search from the
beginning. Or am I missing something?
Links
1. https://www.postgresql.org/mes
ausing segfaults only since 911e702077.
> Anyone have any ideas? (If not, I'll commit and backpatch something like
> the attached patch at some suitable time.)
I would rather propose to rip off special handling of the last item
completely (see the attached patch).
--
Regards,
Alexa
ultixact is filled' or 'gets full' would be
> better. Not sure.
Sounds reasonable as well.
--
Regards,
Alexander Korotkov
On Tue, Oct 27, 2020 at 8:02 PM Alexander Korotkov wrote:
> On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> > Thanks for your review, Alexander!
> > +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> > Other changes seem correct to me too.
> >
that it
> affects multixact scalability much less than sizes of offsets\members
> buffers. I concur that patch 2 of the patchset does not seem documented
> enough.
Thank you. I've made a few more minor adjustments to the patchset.
I'm going to push 0001 and 0003 if there are no objections.
ould work if there are multiple indices
of the same column. We should clearly prefer btree than pg_trgm
gist/gin, and I believe our costing provides this. But we also should
prefer btree_gist/btree_gin than pg_trgm gist/gin, and I'm not sure
our costing provides this especially for gist.
------
Regards,
Alexander Korotkov
lain to the user how to set the new parameter. I think we
should give users an idea what workloads need high values of
multixact_local_cache_entries parameter and what doesn't. Also, we
should explain the negative aspects of high values
multixact_local_cache_entries. Ideally, we should get the advant
On Sat, Oct 3, 2020 at 6:37 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I personally don't have an exact understanding of how strict we are
> > about marking functions immutable. For example,
> > to_tsvector(regconfig, text) is immutable.
>
> Yeah. This is
On Fri, Sep 25, 2020 at 2:02 AM Alexander Korotkov wrote:
> Other opinions?
Given no other opinions yet, I've pushed the both patches.
--
Regards,
Alexander Korotkov
might be backpatched
v13. One thing I don't particularly like is "In standard mode format
string characters are strictly matched or matched to spaces."
Instead, I would like to just strictly match characters and just add
more options to fmt_str[].
Other opinions?
--
Regards,
Alexander Korotkov
that CREATE DOMAIN somehow "emulates" CREATE TYPE.
Could you please, rephrase it? It looks confusing to me yet.
--
Regards,
Alexander Korotkov
shot. But INSERT ON CONFLICT
might have other caveats in this area, it needs careful analysis.
2) Checking unique conflicts inside the index am is already the
encapsulation-breaking hack. Returning the heap tuple for index am
would be even worse hack. We probably should refactor this whole area
before.
--
Regards,
Alexander Korotkov
On Sat, Aug 8, 2020 at 11:49 PM Konstantin Knizhnik
wrote:
> On 08.08.2020 21:18, Alexander Korotkov wrote:
> > On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik
> > wrote:
> >> I agree with your that loosing sequential order of B-Tree pages may have
> >&g
rder sequential within level.
I'm OK with your design for a third-party extension. It's very cool
to have. But I'm -1 for something like this to get into core
PostgreSQL, assuming it's feasible to push some effort and get
state-of-art LSM there.
--
Regards,
Alexander Korotkov
roblem of ordering degradation, because it stores levels in sorted
files.
--
Regards,
Alexander Korotkov
ng, I
think core modifications are inevitable to utilize the power of LSM in
PostgreSQL.
Links
1. https://github.com/google/leveldb/blob/master/doc/impl.md
--
Regards,
Alexander Korotkov
On Wed, Aug 5, 2020 at 1:58 AM Peter Geoghegan wrote:
> On Tue, Aug 4, 2020 at 7:27 AM Alexander Korotkov
> wrote:
> > Thank you for your reminder. Revised patch is attached. Now, the
> > contents of deleted btree pages isn't masked. I've checked that
>
of view LSM as an index AM is far not a full power LSM
for PostgreSQL, but it's still useful. Large insert-only tables can
benefit from LSM. Large tables with many indexes could also benefit,
because non-HOT updates will become cheaper.
--
Regards,
Alexander Korotkov
f index keys. For
lsm, it would be better if vacuum would push delete requests to the
top level of lsm (as specially marked tuples of something). Thanks to
that index deletes could be as efficient as inserts. This is
especially important for lsm with many levels and/or aggressive
vacuum.
--
Regards,
Alexander Korotkov
e patchset from 2020/07/03? I don't get any duplicate OIDs
> with it, and it's already using quite high OIDs (part 4 uses >= 8000,
> part 5 uses >= 9000).
Yep, it appears that I was using the wrong version of patchset.
Patchset from 2020/07/03 works good on the current master.
--
Regards,
Alexander Korotkov
Hi, Peter!
On Sat, Aug 1, 2020 at 3:23 AM Peter Geoghegan wrote:
> On Wed, May 13, 2020 at 4:06 PM Peter Geoghegan wrote:
> > On Mon, May 11, 2020 at 5:56 AM Alexander Korotkov
> > wrote:
> > > Thank you. 2nd patch is proposed for master and makes btree page
> >
On Mon, Jul 20, 2020 at 3:18 PM Justin Pryzby wrote:
> On Wed, Jul 15, 2020 at 03:26:24PM +0300, Alexander Korotkov wrote:
> > On Thu, Jun 18, 2020 at 7:48 PM Winfield, Steven
> > wrote:
> > > Done - thanks again.
> >
> > This patch looks g
ons in terms of
parallel safety. I did just minor adjustments in migration script
comments.
I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
0001-Update-btree_gist-extension-for-parallel-query.patch
Description: Binary data
would be good to use high oid numbers to evade conflicts during
development/review, and rely on committer to set final oids (as
discussed in [1]).
Links
1.
https://www.postgresql.org/message-id/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-%3DeaochT0dd2BN9CQ%40mail.gmail.com
--
Regards,
Alexander Korotkov
On Mon, Jul 13, 2020 at 7:54 PM Jonathan S. Katz wrote:
> On 7/13/20 10:37 AM, Tom Lane wrote:
> > Alexander Korotkov writes:
> >> Good compromise. Done as you proposed.
> >
> > I'm OK with this version.
>
> I saw this was committed and the item was adjuste
On Sat, Jul 11, 2020 at 10:59 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > The proposed patch is attached. This patch is fixes two points:
> > * Adds strategy number and purpose to output of \dAo
> > * Renames "Left/right arg type" columns of \dAp to &
On Fri, Jul 10, 2020 at 2:24 AM Alexander Korotkov wrote:
> On Thu, Jul 9, 2020 at 10:03 PM Jonathan S. Katz wrote:
> > From the RMT perspective, if there is an agreed upon approach (which it
> > sounds like from the above) can someone please commit to working on
> > res
On Thu, Jul 9, 2020 at 4:04 AM Alexander Korotkov wrote:
> I understand both patches as fixes and propose to backpatch them to 12
> if no objections.
Both patches are pushed.
--
Regards,
Alexander Korotkov
se for me the
whole issue is about details :)
But I think we can come to an agreement shortly. And yes, I commit to
resolve this.
--
Regards,
Alexander Korotkov
this is feasible with the current
snapshot model, because keeping full snapshots instead of just xmins
would bloat shared-memory structs and complicate computations. But
CSN can certainly support this optimization.
--
Regards,
Alexander Korotkov
ypass vacuuming this relation if XID is not changed.
This option looks good for me independently of the use case under
consideration. Long-running transactions are an old and well-known
problem. If we can skip some useless work here, let's do this.
--
Regards,
Alexander Korotkov
On Thu, Jul 9, 2020 at 1:20 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > The patchset is attached, sorry for the delay.
>
> > The first patch improves error messages, which appears to be unclear
> > for me. If one applies .double() method to a numeri
l missed in
> 14903f2, making the docs of GIN/SP-GiST less in line with the BRIN
> equivalent, so I have fixed both while on it.
I just read this thread.
Thank you for fixing this!
--
Regards,
Alexander Korotkov
On Wed, Jul 8, 2020 at 1:16 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push 0002 if there is no objection.
> > Regarding 0001, I think my new error messages need review.
>
> I do intend to review these, just didn't get to it yet.
OK, that you for notic
On Mon, Jul 6, 2020 at 3:19 PM Alexander Korotkov wrote:
> The patchset is attached, sorry for the delay.
>
> The first patch improves error messages, which appears to be unclear
> for me. If one applies .double() method to a numeric value, we
> restrict that this numeric v
ash, that's not what the support function's arguments actually are.
> Perhaps names along the lines of "Registered left type" and "Registered
> right type" would put readers in a better frame of mind to understand
> the entries.
+1 for rename "Left arg type"/"Right arg type" to "Registered left
type"/"Registered right type".
--
Regards,
Alexander Korotkov
On Thu, Jun 18, 2020 at 8:04 PM Alexander Korotkov
wrote:
> On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > Thank you for your answer. I'm trying to understand your point.
> > > Standard claims that .double() method should behave
On Sun, Jun 21, 2020 at 2:28 AM Justin Pryzby wrote:
> And a couple more in spgist.sgml (some of which were not added by this patch).
Pushed, thanks!
--
Regards,
Alexander Korotkov
On Sat, Jun 20, 2020 at 10:15 PM Peter Geoghegan wrote:
> On Sat, Jun 20, 2020 at 3:55 AM Alexander Korotkov
> wrote:
> > So, pushed!
>
> Noticed one small thing. You forgot to update this part from the B-Tree docs:
>
> "As shown in Table 37.9, btree defines on
On Sat, Jun 20, 2020 at 6:08 PM Stefan Kaltenbrunner
wrote:
> On 6/20/20 4:46 PM, Alexander Korotkov wrote:
> > On Sat, Jun 20, 2020 at 3:32 PM Erik Rijkers wrote:
> >> The mails that I get today from pgsql-committers contain links (as
> >> usual) to git.postgres
On Thu, Jun 18, 2020 at 8:06 PM Alexander Korotkov
wrote:
> On Wed, Jun 17, 2020 at 2:00 PM Alexander Korotkov
> wrote:
> > On Wed, Jun 17, 2020 at 2:50 AM Peter Geoghegan wrote:
> > > On Tue, Jun 16, 2020 at 4:24 AM Alexander Korotkov
> > > wrote:
> And I can git-pull without error but nothing more recent than this:
I've discovered timeouts while accessing gitmaster.postgresql.org
--
Regards,
Alexander Korotkov
On Sat, Jun 20, 2020 at 1:16 PM Alexander Korotkov
wrote:
> On Fri, Jun 19, 2020 at 10:34 PM Alvaro Herrera
> wrote:
> >
> > On 2020-Jun-15, Michael Paquier wrote:
> >
> > > I have begun my annual study of WAL consistency across replays, and
> > > wal_co
installcheck and this is the first failure I saw after replaying all
> > the generated WAL on a standby. Please note that I have also checked
> > 12, and installcheck passes.
>
> Umm. Alexander, do you an idea of what this is about?
I don't have idea yet, but I'll check this out
--
Regards,
Alexander Korotkov
On Wed, Jun 17, 2020 at 2:00 PM Alexander Korotkov
wrote:
> On Wed, Jun 17, 2020 at 2:50 AM Peter Geoghegan wrote:
> > On Tue, Jun 16, 2020 at 4:24 AM Alexander Korotkov
> > wrote:
> > > Thank you for patience. The documentation patch is attached. I think
> >
On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Thank you for your answer. I'm trying to understand your point.
> > Standard claims that .double() method should behave the same way as
> > CAST to double. However, standard references
On Thu, Jun 18, 2020 at 7:34 PM Alexander Korotkov
wrote:
> Thank you for your answer. I'm trying to understand your point.
> Standard claims that .double() method should behave the same way as
> CAST to double. However, standard references the standard behavior of
> CAST here,
tomatically mean we should extend the .double() jsonpath
method in the same way. Is it correct?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Jun 17, 2020 at 2:50 AM Peter Geoghegan wrote:
> On Tue, Jun 16, 2020 at 4:24 AM Alexander Korotkov
> wrote:
> > Thank you for patience. The documentation patch is attached. I think
> > it requires review by native english speaker.
>
> * "...par
On Thu, May 28, 2020 at 11:02 PM Alexander Korotkov
wrote:
>
> On Thu, May 21, 2020 at 3:17 AM Alexander Korotkov
> wrote:
> >
> > On Thu, May 21, 2020 at 12:37 AM Peter Geoghegan wrote:
> > > Commit 911e7020770 added a variety of new support routines to index
&g
On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
> >> It is entirely clear from the code, the documentation,
> >> and the relevant RFCs that JSONB does not allow NaNs as numeri
N' to numeric NaN. So, standard requires us to do
the same in SQL/JSON.
I didn't find yet what the standard says about serializing NaNs back
to JSON. I'll keep you posted.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ame.
src/common/fe_archive.c => src/fe_utils/archive.c
include/common/fe_archive.h => include/fe_utils/archive.h
> It actually defines functions that clash with functions in the backend,
> so this seems doubly wrong.
Let's have frontend version of RestoreArchivedFile() renamed as well.
What about RestoreArchivedFileFrontend()?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, May 21, 2020 at 3:17 AM Alexander Korotkov
wrote:
>
> On Thu, May 21, 2020 at 12:37 AM Peter Geoghegan wrote:
> > Commit 911e7020770 added a variety of new support routines to index
> > AMs. For example, it added a support function 5 to btree (see
> > BTOPTIONS_PR
ures. Even still, I
> think that the new support functions should get some mention alongside
> the older support functions.
>
> I also wonder whether or not xindex.sgml needs to be updated to
> account for opclass parameters.
Thank you for pointing. I'm going to take a look on this in
On Thu, May 14, 2020 at 1:34 PM Alexander Korotkov
wrote:
> On Thu, May 14, 2020 at 1:30 PM Nikita Glukhov
> wrote:
> > I agree that this patch is an improvement.
>
> OK, I'm going to push this patch if no objections.
> (Sergey doesn't seem to continue involvement in Pos
On Thu, May 14, 2020 at 1:30 PM Nikita Glukhov wrote:
> I agree that this patch is an improvement.
OK, I'm going to push this patch if no objections.
(Sergey doesn't seem to continue involvement in PostgreSQL
development, so it doesn't look like we should wait for him)
--
Alexander Korot
Hi!
On Tue, May 12, 2020 at 12:09 AM Alvaro Herrera
wrote:
> On 2020-Mar-08, Alexander Korotkov wrote:
>
> > Show opclass and opfamily related information in psql
> >
> > This commit provides psql commands for listing operator classes, operator
> > families
s names, because those names
might be confusing for users who are not aware of them. We may
briefly say that new parameters are introduced for GiST for tsvector,
contrib/intarray, contrib/pg_trgm, contrib/ltree, contrib/hstore.
What do you think?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Apr 28, 2020 at 4:05 AM Peter Geoghegan wrote:
> On Mon, Apr 27, 2020 at 4:17 AM Alexander Korotkov
> wrote:
> > > Assuming it doesn't seem we actually need any items on deleted pages,
> > > I can propose to delete them on primary as well. That would make
&
affects core and particular contribs?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e not reflected in the
release notes.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e, perhaps.
+1
You can also take a look at https://github.com/postgrespro/rum
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Apr 27, 2020 at 11:51 AM Alexander Korotkov
wrote:
> On Wed, Apr 22, 2020 at 7:47 PM Peter Geoghegan wrote:
> > On Tue, Apr 21, 2020 at 2:54 AM Alexander Korotkov
> > wrote:
> > > Proposed fix is attached. Spotted by Konstantin Knizhnik,
> > >
On Wed, Apr 22, 2020 at 7:47 PM Peter Geoghegan wrote:
> On Tue, Apr 21, 2020 at 2:54 AM Alexander Korotkov
> wrote:
> > Proposed fix is attached. Spotted by Konstantin Knizhnik,
> > reproduction case and fix from me.
>
> I wonder if we should fix btree_xlog_unlink_p
On Tue, Apr 21, 2020 at 4:59 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 21, 2020 at 7:58 AM Tom Lane wrote:
> >> Yeah, but that was for a security hole. I am doubtful that the
> >> severity of this problem is bad enough to justify jumping throug
On Tue, Apr 21, 2020 at 12:54 PM Alexander Korotkov
wrote:
> I found concurrency bug in amcheck running on replica. When
> btree_xlog_unlink_page() replays changes to replica, deleted page is
> left with no items. But if amcheck steps on such deleted page
> palloc_btree_page() expe
On Tue, Apr 21, 2020 at 7:58 AM Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote:
> >> As a bugfix, I think this should be backpatched. But this patch
> >> requires catalog change. Were similar
On Tue, Apr 21, 2020 at 4:38 AM Michael Paquier wrote:
> On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote:
> > Among all the joined tables, only "pg_index I" is expected to have
> > multiple rows associated with single relation. But we do sum() for
&g
in index "test_x_idx" lacks high key and/or
at least one downlink
Proposed fix is attached. Spotted by Konstantin Knizhnik,
reproduction case and fix from me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix_amcheck_concurr
hould be backpatched. But this patch
requires catalog change. Were similar cases there before? If so,
how did we resolve them?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix_pg_statio_all_tables.patch
Description: Binary data
On Wed, Apr 8, 2020 at 3:43 PM Andres Freund wrote:
> Realistically it still 2-3 hours of proof-reading.
>
> This makes me sad :(
Can we ask RMT to extend feature freeze for this particular patchset?
I think it's reasonable assuming extreme importance of this patchset.
--
Alexander
equest on github.
https://github.com/postgrespro/rum
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Apr 8, 2020 at 2:14 AM Kartyshov Ivan
wrote:
> On 2020-04-08 00:27, Tom Lane wrote:
> > Alexander Korotkov writes:
> » WAIT FOR LSN lsn [ TIMEOUT timeout ]
> >
> > This seems like a really carelessly chosen syntax —- *three* new
> > keywords, when you prob
On Tue, Apr 7, 2020 at 10:58 PM Anna Akenteva wrote:
> Thank you for your review!
> Ivan and I have worked on the patch and tried to address your comments:
I've pushed this. I promise to do careful post-commit review and
resolve any issues arising.
--
Alexander Korotkov
Po
rrent syntax
is limiting us from something.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Apr 7, 2020 at 12:58 AM Kartyshov Ivan
wrote:
> On 2020-04-04 03:14, Alexander Korotkov wrote:
> > I think that now we would be fine with single LSN and single TIMEOUT.
> > In future we may add multiple LSNs/TIMEOUTs or/and support for
> > expressions as LSNs/TIME
On Sun, Apr 5, 2020 at 8:00 PM Tomas Vondra
wrote:
> On Sun, Apr 05, 2020 at 07:33:40PM +0300, Alexander Korotkov wrote:
> >On Sun, Apr 5, 2020 at 6:53 PM Tomas Vondra
> > wrote:
> >> On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote:
> >> >
might use timezone. If
jsonpath doesn't use .datetime() method, it doesn't need timezone for
sure. Also, from the datetime format specifiers we can get that we
don't compare non-timezoned values to timezoned values. So, if we
detect this jsonpath never uses timezone, we can consider SQL/JSON
clause as immutable.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Apr 5, 2020 at 6:53 PM Tomas Vondra
wrote:
> On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote:
> >On Thu, Apr 2, 2020 at 5:29 AM Tomas Vondra
> > wrote:
> >> On Sun, Dec 01, 2019 at 10:55:02AM +0900, Michael Paquier wrote:
> >> >On T
On Sun, Apr 5, 2020 at 6:51 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'd like to give this patchset a chance for v13. I'm going to make
> > another pass trough this patchset. If I wouldn't find serious issues,
> > I'm going to commit it. Any objections?
>
chance for v13. I'm going to make
another pass trough this patchset. If I wouldn't find serious issues,
I'm going to commit it. Any objections?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
inning of
transaction is good idea. Separate WAIT FOR LSN statement called in
the middle of transaction looks problematic for me. Imagine we have RR
isolation and already acquired the snapshot. Then out snapshot can
block applying wal records, which we are waiting for. That would be
implicit deadl
On Wed, Apr 1, 2020 at 2:59 PM Justin Pryzby wrote:
> On Wed, Apr 01, 2020 at 02:53:41PM +0300, Alexander Korotkov wrote:
> > On Tue, Mar 31, 2020 at 12:15 PM Alexander Korotkov
> > wrote:
> > > What is XXX supposed to be?
> > >
> > > The rest of p
On Tue, Mar 31, 2020 at 12:15 PM Alexander Korotkov
wrote:
> What is XXX supposed to be?
>
> The rest of patch looks good to me.
I've pushed the patch excepts XXX. Thank you.
You're welcome to clarify XXX and/or do additional corrections.
--
Alexander Korotkov
Postgres Professio
On Tue, Mar 31, 2020 at 5:44 AM Justin Pryzby wrote:
> On Sat, Mar 28, 2020 at 06:05:51PM +0300, Alexander Korotkov wrote:
> > On Wed, Mar 18, 2020 at 3:28 AM Nikita Glukhov
> > wrote:
> > > Attached new version of reordered patches.
> >
> > I'm going to
On Sun, Mar 29, 2020 at 9:50 PM Andres Freund wrote:
> On March 29, 2020 11:24:32 AM PDT, Alexander Korotkov
> wrote:
> > clearly a big win on majority
> >of workloads, I think we still need to investigate different workloads
> >on different hardware to ensur
xt couple of days. If you have an objection, please feel free.
I'm fine with patchset attached. Sorry for late reply.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
very cool results.
Despite this patchset is expected to be clearly a big win on majority
of workloads, I think we still need to investigate different workloads
on different hardware to ensure there is no regression.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
should we allow reloption to both
disable feature and disable reloption. I think we don't have a
precedent in the codebase yet. We could allow -2 (disable reloption)
and -1 (disable feature) for reloption. Opinions?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Mar 24, 2020 at 3:38 PM Amit Kapila wrote:
> On Sun, Jan 12, 2020 at 3:33 AM Alexander Korotkov
> wrote:
> >
> > On Wed, Jan 8, 2020 at 4:37 PM Tom Lane wrote:
> > > Heikki Linnakangas writes:
> > > > On 01/11/2019 01:50, Alexander Korotkov w
501 - 600 of 1169 matches
Mail list logo
