mail address subscribed to the pgsql-hackers mailing list?
AFAIK, moderation is only applied for non-subscribers.
--
Regards,
Alexander Korotkov
cedure does not invalidate relation's opclass options cache.
> >
>
> Seems like that.
I think opclass options procedure shouldn't normally change opclass
options chache. Before installation of options procedure, there
should be no options. And options procedure shouldn't change the
defaults in this case.
--
Regards,
Alexander Korotkov
On Sun, Mar 6, 2022 at 8:28 PM Tomas Vondra
wrote:
> On 3/6/22 08:09, Alexander Korotkov wrote:
> > Sorry for this terrible oversight by me.
> >
> > On Sat, Mar 5, 2022 at 10:13 AM Tomas Vondra
> > wrote:
> >> On 3/4/22 23:09, Nikita Glukhov wrote:
>
On Tue, Mar 8, 2022 at 2:05 AM Alexander Korotkov wrote:
> On Sun, Mar 6, 2022 at 8:28 PM Tomas Vondra
> wrote:
> > On 3/6/22 08:09, Alexander Korotkov wrote:
> > > Sorry for this terrible oversight by me.
> > >
> > > On Sat, Mar 5, 2022 at 10:13 AM Tomas V
On Thu, Mar 10, 2022 at 6:39 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Good. The revised patch is attached. Instead of adding argument to
> > LTREE_GET_ASIGLEN(), it introduces separate LTREE_GET_SIGLEN() and
> > LTREE_GET_ASIGLEN() macros.
>
> Um ... wh
know
> what you think.
I'm not a localization expert. Could you clarify what localization
messages should look like if we switch to XID_FMT? And will we have
to change them if change the definition of XID_FMT?
--
Regards,
Alexander Korotkov
e error messages eventually. Please let us know
> > what you think.
>
> This is not a question of simplification. Translatable messages with
> embedded macros won't work. This patch isn't going to be acceptable.
I've suspected this, but wasn't sure. Thank you for clarification.
--
Regards,
Alexander Korotkov
On Tue, Dec 1, 2020 at 6:26 AM Krunal Bauskar wrote:
> On Tue, 1 Dec 2020 at 02:31, Alexander Korotkov wrote:
>> BTW, how do you get that required gcc version is 9.4? I've managed to
>> use LSE with gcc 9.3.
>
> Did they backported it to 9.3?
> I am just look
gt; Anyway, I believe that the apparent gap between HEAD and the other
> curves at -c 4 is probably an artifact: HEAD had two 180K-ish results
> and one 220K-ish result, while the other curves had the reverse, so
> the medians are different but there's probably not any non-chance
>
t guarantee that patch doesn't cause
regression of some ARM. Additionally, the effect of the CAS patch
even for Kunpeng seems modest. It makes the drop off of TPS more
smooth, but it doesn't change the trend.
--
Regards,
Alexander Korotkov
. It's probably because he
runs the tests with a low number of clients.
--
Regards,
Alexander Korotkov
org/message-id/741389.1606530957%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
On Thu, Nov 12, 2020 at 4:09 PM Alexander Korotkov wrote:
> This issue looks like the much more complex design 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
> ad
On Tue, Dec 1, 2020 at 7:57 PM Zidenberg, Tsahi wrote:
> > On 01/12/2020, 16:59, "Alexander Korotkov" wrote:
> > On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar
> > wrote:
> > > FWIW, here is an earlier discussion on the same (also added the
> >
different low-level
implementations of CAS-loops for Power, ARM and rest platforms with
single code for LWLockAttempLock() and others. However, I see that
modern ARM tends to efficiently implement LSE. Power doesn't seem to
be very popular. So, I'm going to give up with this for now.
--
Regards,
Alexander Korotkov
ut custom C-function, and also run it across various ARM
machines.
Links
1. https://www.postgresql.org/message-id/741389.1606530957%40sss.pgh.pa.us
2. https://www.postgresql.org/message-id/1274781.1606760475%40sss.pgh.pa.us
3.
https://linux-concepts.blogspot.com/2018/05/spinlock-implementation-in-arm.html
--
Regards,
Alexander Korotkov
gt; > >>> On Mon, Nov 30, 2020 at 04:12:29PM +0300, Alexander Korotkov wrote:
> > >>> The idea of an opaque field in SubscriptingRef structure is more
> > >>> attractive to me. Could you please implement it?
> >
> > >> Sure, doesn't se
On Fri, Dec 4, 2020 at 9:29 PM Alvaro Herrera wrote:
> On 2020-Nov-25, Alexander Korotkov wrote:
> > In the view of above, I'd like to propose a POC patch, which implements new
> > builtin infrastructure for reproduction of concurrency issues in automated
> > test suite
On Fri, Dec 4, 2020 at 9:57 PM Peter Geoghegan wrote:
> On Wed, Nov 25, 2020 at 6:11 AM Alexander Korotkov
> wrote:
> > While the postgres community does a great job on investigating and fixing
> > the problems, our ability to reproduce concurrency issues in the source
>
patch, but it wouldn't be
fair to completely throw it away. It still might be useful for
LSE-disabled builds.
--
Regards,
Alexander Korotkov
Hi!
On Mon, Dec 7, 2020 at 9:10 AM Craig Ringer
wrote:
> On Wed, 25 Nov 2020 at 22:11, Alexander Korotkov wrote:
>> PostgreSQL is a complex multi-process system, and we are periodically faced
>> with complicated concurrency issues. While the postgres community does a
On Mon, Nov 30, 2020 at 11:39 PM Alexander Korotkov
wrote:
> On Mon, Nov 30, 2020 at 10:35 PM Alexander Korotkov
> wrote:
> > On Sun, Nov 29, 2020 at 11:53 PM Paul A Jungwirth
> > wrote:
> > >
> > > On Sun, Nov 29, 2020 at 11:43 AM Alexander Korotkov
> &g
On Tue, Dec 8, 2020 at 1:26 PM Andrey Borodin wrote:
> > 25 нояб. 2020 г., в 19:10, Alexander Korotkov
> > написал(а):
> >
> > In the code stop events are defined using macro STOPEVENT(event_id,
> > params). The 'params' should be a function call, and
27;ve nothing against changing this to a more informative message, but
that should be done globally. And this change isn't directly related
to multirage. Feel free to propose a patch improving this.
--
Regards,
Alexander Korotkov
On Thu, Dec 17, 2020 at 1:03 AM Alexander Korotkov wrote:
> On Thu, Dec 17, 2020 at 12:54 AM Zhihong Yu wrote:
> > +* The idea is to prepend underscores as needed until we make a name
> > that
> > +* doesn't collide with anything ...
> >
> > I wo
On Thu, Dec 17, 2020 at 2:37 AM Zhihong Yu wrote:
> Letting user manually name the multirange (after a few automatic attempts)
> seems reasonable.
Accepted. Thank you for your feedback.
--
Regards,
Alexander Korotkov
On Thu, Dec 17, 2020 at 10:10 PM Alexander Korotkov
wrote:
>
> I think this patch is very close to committable. I'm going to spend
> some more time further polishing it and commit (if I don't find a
> major issue or face objections).
The main patch is committed.
On Sun, Dec 27, 2020 at 8:52 PM Zhihong Yu wrote:
> This is not an ideal way to index multirages, but something we can easily
> have.
>
> typo: multiranges
Thanks for catching. I will revise the commit message before committing.
--
Regards,
Alexander Korotkov
I'm
not a big fan of this name). FWIW, such a new access method would
need a lot of work to bring it to commit. I don't think it would be
reasonable, before multiranges get popular.
Regarding the GiST opclass, it seems the best we can do in GiST.
--
Regards,
Alexander Korotkov
Hi!
On Wed, Jan 6, 2021 at 8:18 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > # select to_tsvector('pg_class foo') @@ websearch_to_tsquery('"pg_class
> > foo"');
> > ?column?
> > --
> > f
>
> Yeah, surely th
Hi, Thomas!
On Fri, Feb 12, 2021 at 12:04 AM Thomas Munro wrote:
> On Tue, Feb 9, 2021 at 1:34 PM Alexander Korotkov
> wrote:
> > Could we have both cfbot + buildfarm animals?
> For cfbot, yeah it does seem like a good idea to throw whatever code
> sanitiser stuff we can
arguments to the attribute. Acceptable values for no_sanitize match
those acceptable by the -fsanitize command-line option."
Yes, let's wait for more feedback from buildfarm and fix the version
requirement.
> Once this does settle, should we consider back-patching so that it's
> possible to run alignment checks in the back branches too?
+1
--
Regards,
Alexander Korotkov
On Sun, Feb 14, 2021 at 1:59 AM Tom Lane wrote:
> I wrote:
> > Alexander Korotkov writes:
> >> On Fri, Feb 12, 2021 at 8:19 PM Tom Lane wrote:
> >>> Once this does settle, should we consider back-patching so that it's
> >>> possible to run align
o me 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
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.
> >
* for details.
>
> Perhaps 'till the next multixact is filled' or 'gets full' would be
> better. Not sure.
Sounds reasonable as well.
--
Regards,
Alexander Korotkov
g since
8.x, it started causing 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).
squery('pg_class <-> foo');
to_tsquery
--
( 'pg' & 'class' ) <-> 'foo'
I think if a user writes 'pg_class <-> foo', then it's expected to
match 'pg_class foo' independently
ur gist cost estimate is 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
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/
fdvJhO1qutziOp%3Ddy8TO8Xb4L38BxgKG4RPa1up1Lzh_UQ%40mail.gmail.com
--
Regards,
Alexander Korotkov
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
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
N’);
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
The feedback is welcome.
Links.
1. https://www.postgresql.org/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%40hi
S on arm
would be a win. But there could 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
s low as 4.
Especially 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
On Fri, Nov 27, 2020 at 2:20 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Thu, Nov 26, 2020 at 1:32 PM Heikki Linnakangas wrote:
> >> Is there some official ARM documentation, like a programmer's reference
> >> manual or something like t
Hi!
I've found this patch is RFC on commitfest application. I've quickly
checked if it's really ready for commit. It seems there are still
unaddressed review notes. I'm going to switch it to WFA.
--
Regards,
Alexander Korotkov
ed version of this patch, including a bunch of cleanup
> from Alvaro. (Thanks Alvaro!)
I'd like to review this patch. Could you please rebase it once again? Thanks.
--
Regards,
Alexander Korotkov
swpal/casa
instructions as well.
--
Regards,
Alexander Korotkov
wertypeoid[MAX_SUBSCRIPT_DEPTH];
--
Regards,
Alexander Korotkov
ng "-march=armv8-a+lse". I'm going to make
some experiments on a multicore AWS graviton2 instance with different
atomic implementation.
--
Regards,
Alexander Korotkov
compiler.
I've checked that gcc 9.3 with "-march=armv8-a+lse" option uses LSE atomics...
--
Regards,
Alexander Korotkov
On Sun, Nov 29, 2020 at 8:11 PM Paul A Jungwirth
wrote:
> On Fri, Nov 27, 2020 at 12:35 AM Alexander Korotkov
> wrote:
> > I'd like to review this patch. Could you please rebase it once again?
> > Thanks.
>
> Thanks! Here is a rebased version. It also includes o
ple clang...
Links
1. https://www.postgresql.org/message-id/663376.1606432828%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
On Mon, Nov 30, 2020 at 2:33 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Fri, Nov 27, 2020 at 12:13:48PM +0300, Alexander Korotkov wrote:
> > I've started to review this patch.
>
> Thanks!
>
> > My first question is whether we're
> > abl
the doubts could you
please provide assembly of SpinLockAcquire for following clang
options.
"-O2"
"-O2 -march=armv8-a+lse"
"-O2 -march=armv8-a"
Thank you!
Links
1. https://www.postgresql.org/message-id/663376.1606432828%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
On Sun, Nov 29, 2020 at 11:53 PM Paul A Jungwirth
wrote:
>
> On Sun, Nov 29, 2020 at 11:43 AM Alexander Korotkov
> wrote:
> > Thank you. Could you please, update doc/src/sgml/catalogs.sgml,
> > because pg_type and pg_range catalogs are updated.
>
> Attached! :
On Mon, Nov 30, 2020 at 10:35 PM Alexander Korotkov
wrote:
> On Sun, Nov 29, 2020 at 11:53 PM Paul A Jungwirth
> wrote:
> >
> > On Sun, Nov 29, 2020 at 11:43 AM Alexander Korotkov
> > wrote:
> > > Thank you. Could you please, update doc/src/sgml/catalog
On Mon, Nov 30, 2020 at 9:21 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I tend to think that LSE is enabled by default in Apple's clang based
> > on your previous message[1]. In order to dispel the doubts could you
> > please provide assembly of SpinLockA
ng the appropriate
package/using the appropriate compiler (especially if we publish
explicit instructions for that). In the same way such advanced users
tune Linux kernel etc.
BTW, how do you get that required gcc version is 9.4? I've managed to
use LSE with gcc 9.3.
------
Regards,
Alexander Korotkov
ected. But at the second sight, the lax
mode is used by default and current behavior may look too surprising.
My proposal is to make everything after the ** operator use strict mode
(patch attached). I think this shouldn't be backpatched, just applied to
the v14. Other suggestions?
Links
1.
https://www.postgresql.org/message-id/16828-2b0229babfad2d8c%40postgresql.org
--
Regards,
Alexander Korotkov
jsonpath_double_star_strict_mode.patch
Description: Binary data
On Thu, Jan 7, 2021 at 6:36 AM Alexander Korotkov wrote:
>
> > I read your patch over quickly and it seems like a reasonable
> > approach (but sadly underdocumented). Can we extend the idea
> > to fix the to_tsquery case?
>
> Sure, I'll provide a revised patch.
Hi, Alvaro!
Thank you for your feedback.
On Wed, Jan 20, 2021 at 9:16 PM Alvaro Herrera wrote:
> On 2021-Jan-20, Alexander Korotkov wrote:
>
> > My proposal is to make everything after the ** operator use strict mode
> > (patch attached). I think this shouldn't be backp
ot to add tsearch.out to the patch.
BTW, you mentioned you read the documentation. Do you think it needs
to be adjusted accordingly to the patch?
--
Regards,
Alexander Korotkov
On Thu, Jan 21, 2021 at 12:38 PM Thomas Kellerer wrote:
> Alexander Korotkov schrieb am 20.01.2021 um 18:13:
> > We have a bug report which says that jsonpath ** operator behaves strangely
> > in the lax mode [1].
> That report was from me ;)
>
> Thanks for looking into
On Thu, Jan 21, 2021 at 4:35 PM Alvaro Herrera wrote:
> On 2021-Jan-21, Alexander Korotkov wrote:
>
> > Requiring strict mode for ** is a solution, but probably too restrictive...
> >
> > What do you think about making just subsequent accessor after ** not
> > to u
On Mon, Jan 25, 2021 at 6:33 PM Alexander Korotkov wrote:
> On Thu, Jan 21, 2021 at 4:35 PM Alvaro Herrera
> wrote:
> > On 2021-Jan-21, Alexander Korotkov wrote:
> >
> > > Requiring strict mode for ** is a solution, but probably too
> > > restrictive...
On Tue, Jan 26, 2021 at 4:31 AM Neil Chen wrote:
> On Mon, Jan 25, 2021 at 11:25 PM Alexander Korotkov
> wrote:
>>
>>
>> BTW, you mentioned you read the documentation. Do you think it needs
>> to be adjusted accordingly to the patch?
>>
>
> Yes, I chec
themself looks good for me. I'm
going to push this if no objections.
--
Regards,
Alexander Korotkov
On Fri, Jan 29, 2021 at 7:01 PM Alexander Korotkov wrote:
> On Thu, Jan 21, 2021 at 11:14 PM Pavel Stehule
> wrote:
> >> Looks good, I've applied it, thanks.
> >
> > I tested last set of patches
> >
> > 1. There is no problem with patching and comp
Hi, Tom!
Thank you for taking care of this.
On Mon, Feb 8, 2021 at 3:47 AM Tom Lane wrote:
>
> [ redirecting to -hackers ]
>
> Alexander Korotkov writes:
> >> BTW, I managed to reproduce the issue by compiling with CFLAGS="-O0
> >> -fsanitize=alignment -fsan
ir version history and sanitizers seem
> to have come in around clang 7, so I propose the attached (where
> I worked a bit harder on the comment, too).
Looks good to me. Thank you for revising!
--
Regards,
Alexander Korotkov
On Thu, Feb 11, 2021 at 9:46 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Feb 8, 2021 at 7:49 PM Tom Lane wrote:
> >> Ugh, no it isn't: even pretty recent clang releases only define
> >> __GNUC__ as 4. It looks like we need a separate test on cl
Hi!
On Thu, Jan 6, 2022 at 3:02 AM Bruce Momjian wrote:
>
> On Thu, Dec 30, 2021 at 03:15:16PM +0300, Maxim Orlov wrote:
> > PFA updated working patch v6 for PG15 development cycle.
> > It is based on a patch by Alexander Korotkov version 5 [5] with a few fixes,
> > ref
uot; approach was the first tried.
https://github.com/postgrespro/pg_pageprep
But it appears to be very difficult and unreliable. After investing
many months into pg_pageprep, "double xmax" approach appears to be
very fast to implement and reliable.
--
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
> >
>
> Did you use the 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
to be deleted without information of 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
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
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
ne in
extension (at least in the reasonable way). But, frankly speaking, 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
e a
problem of ordering degradation, because it stores levels in sorted
files.
------
Regards,
Alexander Korotkov
age
order 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
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
27;t match the query snapshot. 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
. I suggest
postponing it. Leave the options immutable, until we get some solid
use-cases of mutable options.
--
Regards,
Alexander Korotkov
.2.1 Requirements for single-copy atomicity" and it seemed
> like we should turn this on for __aarch64__. It goes back to the
> original ARMv8-A so should cover all 64 bit ARM systems.
That should be very good because ARM gains popularity and the effect
of atomic read is significant
--
Regards,
Alexander Korotkov
me for
ExpireOldKnownAssignedTransactionIds() indicating that it could modify
lastOverflowedXid as well. Any ideas?
Should ExpireAllKnownAssignedTransactionIds() be also involved here?
--
Regards,
Alexander Korotkov
message. Let me know if you have further
suggestions.
I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
0001-Reset-lastOverflowedXid-on-standby-when-needed.patch
Description: Binary data
Hi!
On Fri, Nov 5, 2021 at 10:31 AM Kyotaro Horiguchi
wrote:
> At Thu, 4 Nov 2021 01:07:05 +0300, Alexander Korotkov
> wrote in
> > On Wed, Nov 3, 2021 at 8:51 PM Simon Riggs
> > wrote:
> > > It is however, an undocumented modularity violation. I think that is
>
can use just uint32
instead of pg_atomic_uint32.
--
Regards,
Alexander Korotkov
an underflow, because we might consider a very bad
penalty as very good (or vise versa). But it still affects only index
quality, not correctness.
Any thoughts?
--
Regards,
Alexander Korotkov
On Wed, Mar 21, 2018 at 9:51 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Mar 8, 2018 at 7:13 PM, Anastasia Lubennikova <
> a.lubennik...@postgrespro.ru> wrote:
>
>> 06.03.2018 11:52, Thomas Munro:
>>
>>> On Wed, Jan 31, 2018 at
tor for
prefix search without any preliminary discussion. However, personally I
don't
have better ideas :)
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Mar 24, 2018 at 5:21 AM, Peter Geoghegan wrote:
> On Thu, Mar 22, 2018 at 8:23 AM, Alexander Korotkov
> wrote:
> >> * There is minor formatting issue in this part of code. Some spaces
> need
> >> to be replaced with tabs.
> >> +IndexTuple
> &
e changes.
>
So, as I get you're proposing to introduce INDEX_ALT_TID_MASK flag
which would indicate that we're storing something special in the t_tid
offset. And that should help us not only for covering indexes, but also for
further btree enhancements including suffix
riginal. That also seems to cause extra overhead. This is why I've moved
PredicateLockPageSplit() into loop where we do assign new buffers.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Predicate-Locking-in-gist-index_v11.patch
Description: Binary data
On Tue, Mar 27, 2018 at 11:55 AM, Masahiko Sawada
wrote:
> On Thu, Mar 22, 2018 at 9:24 PM, Alexander Korotkov
> wrote:
> > However, I see that you are comparing relative change of num_heap_tuples
> > before and after vacuum to vacuum_cleanup_index_scale_factor.
> >
1 - 100 of 1435 matches
Mail list logo
