me for
ExpireOldKnownAssignedTransactionIds() indicating that it could modify
lastOverflowedXid as well. Any ideas?
Should ExpireAllKnownAssignedTransactionIds() be also involved here?
--
Regards,
Alexander Korotkov
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
poning it. Leave the options immutable, until we get some solid
use-cases of mutable options.
--
Regards,
Alexander Korotkov
On Tue, Sep 21, 2021 at 2:07 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Sep 20, 2021 at 10:48 PM Andres Freund wrote:
> >> I assume you're planning to backpatch this?
>
> > Yes.
>
> Probably good to wait 24 hours until 14rc1 has been tagged.
O
On Mon, Sep 20, 2021 at 10:48 PM Andres Freund wrote:
> On 2021-09-19 18:45:45 +0300, Alexander Korotkov wrote:
> > Any objections to pushing this?
>
> lgtm
Thanks!
> I assume you're planning to backpatch this?
Yes.
--
Regards,
Alexander Korotkov
On Sat, Sep 18, 2021 at 11:35 PM Alvaro Herrera wrote:
> On 2021-Sep-18, Alexander Korotkov wrote:
>
> > I see now. I think I'm rather favoring splitting visibilitymap.h.
>
> Agreed, this looks sane to me. However, I think the
> VM_ALL_{VISIBLE,FROZEN} macros should rema
Hi,
On Sat, Sep 18, 2021 at 3:06 AM Andres Freund wrote:
> On 2021-09-18 02:51:09 +0300, Alexander Korotkov wrote:
> > On Tue, Sep 14, 2021 at 6:53 AM Tom Lane wrote:
> > > Without having looked at the details, I think using a forward-declare
> > > to
litting visibilitymap_maros.h from
visibilitymap.h. What do you think?
--
Regards,
Alexander Korotkov
0001-Split-macros-from-visibilitymap.h-into-a-separate-h-.patch
Description: Binary data
;
> Ugh, yeah, that's entirely against policy.
I see. This is my oversight, sorry for that.
--
Regards,
Alexander Korotkov
On Thu, Jul 15, 2021 at 10:27 PM Jonathan S. Katz wrote:
> On 7/15/21 12:26 PM, Alexander Korotkov wrote:
> > On Thu, Jul 15, 2021 at 6:47 PM Tom Lane wrote:
> >> Yeah, that seems pretty horrid. I still don't like the way the
> >> array casts were done, but I'd be o
seems pretty horrid. I still don't like the way the
> array casts were done, but I'd be okay with pushing the unnest
> addition.
I agree that array casts require better polymorphism and should be
considered for pg15.
+1 for just unnest().
--
Regards,
Alexander Korotkov
On Tue, Jul 13, 2021 at 5:29 PM Alvaro Herrera wrote:
>
> On 2021-Jul-13, Alexander Korotkov wrote:
>
> > > To be clear, do you mean with or without this hunk ?
> > >
> > > - oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
&g
On Tue, Jul 13, 2021 at 5:07 PM Justin Pryzby wrote:
> On Tue, Jul 13, 2021 at 03:11:16PM +0300, Alexander Korotkov wrote:
> > On Sun, Jul 11, 2021 at 1:20 AM Justin Pryzby wrote:
> > > On Sun, Jul 11, 2021 at 01:00:27AM +0300, Alexander Korotkov wrote:
> > > > O
On Sun, Jul 11, 2021 at 1:20 AM Justin Pryzby wrote:
> On Sun, Jul 11, 2021 at 01:00:27AM +0300, Alexander Korotkov wrote:
> > On Sat, Jul 10, 2021 at 7:34 PM Alvaro Herrera
> > wrote:
> > > On 2021-Jun-27, Alexander Korotkov wrote:
> > >
> > >
On Sun, Jul 11, 2021 at 1:28 AM Tom Lane wrote:
> Justin Pryzby writes:
> > On Sun, Jul 11, 2021 at 01:00:27AM +0300, Alexander Korotkov wrote:
> >> True, but I'm a bit uncomfortable about user instances with different
> >> catalogs but the same catversions.
On Sat, Jul 10, 2021 at 7:34 PM Alvaro Herrera wrote:
> On 2021-Jun-27, Alexander Korotkov wrote:
>
> > BTW, I found some small inconsistencies in the declaration of
> > multirange operators in the system catalog. Nothing critical, but if
> > we decide to bump catvers
ccess and few bugs.
Congratulations to Daniel and John! Well deserved promotion!
--
Regards,
Alexander Korotkov
On Mon, Jun 21, 2021 at 1:24 AM Alexander Korotkov wrote:
> On Sun, Jun 20, 2021 at 11:09 AM Noah Misch wrote:
> > On Sat, Jun 19, 2021 at 10:05:09PM -0400, Tom Lane wrote:
> > > Alexander Korotkov writes:
> > > > I also don't feel comfortable hurr
That's quite an amount of work, but I think this
would be a great illustration of the advantages of this decoupling.
--
Regards,
Alexander Korotkov
n ability to use B-tree opclasses directly in GiST and GIN.
--
Regards,
Alexander Korotkov
On Sun, Jun 20, 2021 at 11:09 AM Noah Misch wrote:
> On Sat, Jun 19, 2021 at 10:05:09PM -0400, Tom Lane wrote:
> > Alexander Korotkov writes:
> > > I also don't feel comfortable hurrying with unnest part to beta2.
> > > According to the open items wiki page, t
On Sat, Jun 19, 2021 at 7:35 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Patch successfully passed commitfest.cputube.org. I'm going to
> > re-push it if there are no objections.
>
> I'm still not happy about the way you've done the multirange-to-array
> part.
On Thu, Jun 17, 2021 at 7:54 PM Alexander Korotkov wrote:
> On Wed, Jun 16, 2021 at 3:44 PM Alexander Korotkov
> wrote:
> > On Tue, Jun 15, 2021 at 8:18 PM Tom Lane wrote:
> > > Alexander Korotkov writes:
> > > > I did run "check-world", but it passe
On Wed, Jun 16, 2021 at 3:44 PM Alexander Korotkov wrote:
> On Tue, Jun 15, 2021 at 8:18 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > I did run "check-world", but it passed for me. Probably the same
> > > reason it passed for some buildfarm a
On Tue, Jun 15, 2021 at 8:18 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I did run "check-world", but it passed for me. Probably the same
> > reason it passed for some buildfarm animals...
>
> It looks to me like the proximate problem is that you shoul
On Tue, Jun 15, 2021 at 9:43 PM Andrew Dunstan wrote:
> On 6/15/21 12:06 PM, Alexander Korotkov wrote:
> > On Tue, Jun 15, 2021 at 4:49 PM Tom Lane wrote:
> >> Alexander Korotkov writes:
> >>> Pushed! Thanks to thread participants for raising this topic and
ired for this
function. Not sure if it worth it to introduce a new polymorphic
function for this use case.
--
Regards,
Alexander Korotkov
On Tue, Jun 15, 2021 at 8:18 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I did run "check-world", but it passed for me. Probably the same
> > reason it passed for some buildfarm animals...
>
> The only buildfarm animals that have passed since this went i
On Tue, Jun 15, 2021 at 4:49 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Pushed! Thanks to thread participants for raising this topic and
> > review. I'll be around to resolve issues if any.
>
> Buildfarm is pretty thoroughly unhappy. Did you do a "check-wor
On Sun, Jun 13, 2021 at 2:48 PM Alexander Korotkov wrote:
> On Fri, Jun 11, 2021 at 11:16 PM Tom Lane wrote:
> >
> > Alexander Korotkov writes:
> > > What about "Range/Multirange Functions and Operators"?
> >
> > Better than a comma, I
On Mon, Jun 14, 2021 at 4:14 PM Alexander Korotkov wrote:
> On Mon, Jun 14, 2021 at 3:50 PM Jonathan S. Katz wrote:
> > On 6/13/21 5:18 PM, Alexander Korotkov wrote:
> >
> > >> "Expands an array into a set of rows. The array's elements are read out
> > >
On Mon, Jun 14, 2021 at 3:50 PM Jonathan S. Katz wrote:
> On 6/13/21 5:18 PM, Alexander Korotkov wrote:
>
> >> "Expands an array into a set of rows. The array's elements are read out
> >> in storage order."
> >>
> >> If we tweak
ding).
> +
>
> to be a bit more specific. However, I think this is also bordering on
> overengineering the text, given there has been a lack of feedback on the
> "unnest" array function description being confusing.
I think it's not necessarily to say about rows here. Our
documentation already has already a number of examples, where we
describe set of returned values without speaking about rows including:
json_array_elements, json_array_elements_text, json_object_keys,
pg_listening_channels, pg_tablespace_databases...
--
Regards,
Alexander Korotkov
Therefore, I prefer to stay with "myself".
--
Regards,
Alexander Korotkov
On Fri, Jun 11, 2021 at 11:16 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > What about "Range/Multirange Functions and Operators"?
>
> Better than a comma, I guess. Personally I didn't have a
> problem with the form with two "ands".
Thank
On Sun, Jun 13, 2021 at 2:58 AM Alexander Korotkov wrote:
> On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz wrote:
> > On 6/12/21 5:57 PM, Alexander Korotkov wrote:
> > > On Sat, Jun 12, 2021 at 2:44 AM Alexander Korotkov
> > > wrote:
> > >> ()On Sat
On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz wrote:
> On 6/12/21 5:57 PM, Alexander Korotkov wrote:
> > On Sat, Jun 12, 2021 at 2:44 AM Alexander Korotkov
> > wrote:
> >> ()On Sat, Jun 12, 2021 at 2:30 AM Justin Pryzby
> >> wrote:
> >>> On Fri
On Sat, Jun 12, 2021 at 2:44 AM Alexander Korotkov wrote:
> ()On Sat, Jun 12, 2021 at 2:30 AM Justin Pryzby wrote:
> > On Fri, Jun 11, 2021 at 11:37:58PM +0300, Alexander Korotkov wrote:
> > > On Fri, Jun 11, 2021 at 1:04 AM Justin Pryzby
> > > wrote:
> > &g
()On Sat, Jun 12, 2021 at 2:30 AM Justin Pryzby wrote:
> On Fri, Jun 11, 2021 at 11:37:58PM +0300, Alexander Korotkov wrote:
> > On Fri, Jun 11, 2021 at 1:04 AM Justin Pryzby wrote:
> > >
> > > +{ oid => '1293', descr => 'expand mutlirange to set of rang
s.
--
Regards,
Alexander Korotkov
multirange_unnest_cast_to_array.patch
Description: Binary data
t's better
> to keep this section heading aligned with all of its siblings.
What about "Range/Multirange Functions and Operators"?
--
Regards,
Alexander Korotkov
his
section "Range and Multirange Functions and Operators"?
--
Regards,
Alexander Korotkov
On Thu, Jun 10, 2021 at 8:57 PM Jonathan S. Katz wrote:
> On 6/10/21 1:24 PM, Alexander Korotkov wrote:
> > I agree that unnest(), cast to array and subscription are missing
> > points. Proper subscription support requires expanded object
> > handling. And that s
uires expanded object
handling. And that seems too late for v14. But unnset() and cast to
array seems trivial. I've drafted unnest support (attached). I'm
going to add also cast to the array, tests, and docs within a day.
Stay tuned :)
--
Regards,
Alexander Korotkov
multirange_unnest.patch
Description: Binary data
On Mon, May 10, 2021 at 3:41 AM Michael Paquier wrote:
> On Sun, May 09, 2021 at 11:17:47PM +0300, Alexander Korotkov wrote:
> > I propose backpatching this to 12 when jsonpath was introduced. It
> > seems useful to have this docs improvement every release supporti
.On Tue, May 11, 2021 at 11:31 PM Bruce Momjian wrote:
> On Tue, May 11, 2021 at 01:16:38PM +0300, Alexander Korotkov wrote:
> > > OK, what symbols trigger this change? Underscore? What else?
> >
> > Any symbol, which is recognized as a separator by full-text parser,
&g
On Tue, May 11, 2021 at 5:34 AM Bruce Momjian wrote:
> On Mon, May 10, 2021 at 04:02:27PM +0300, Alexander Korotkov wrote:
> > Hi, Bruce!
> >
> > On Mon, May 10, 2021 at 9:03 AM Bruce Momjian wrote:
> > > I have committed the first draft of the PG 14 release note
ption for the items related to me.
* Improve handling of compound words in to_tsquery() and
websearch_to_tsquery() (Alexander Korotkov)
Compound words are now transformed into parts connected with phrase
search operators. For example, to_tsquery('pg_class') becomes 'pg <->
class' instea
On Sun, May 9, 2021 at 4:01 AM Alexander Korotkov wrote:
> On Sat, May 8, 2021 at 7:09 PM Erik Rijkers wrote:
> > On 5/8/21 3:48 AM, Michael Paquier wrote:
> > > On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
> > >> The JSON doc has this exampl
ore precise here? "strings" looks to much generic to
> > me in this context when actually referring to a set of path of keys in
> > a JSON blob.
>
> Yes, "string values" is probably another small improvement.
What about the attached patch? Wording "string values of the root
object" seems most precise to me.
--
Regards,
Alexander Korotkov
doc_jsonpath_like_regex_example.patch
Description: Binary data
On Sun, May 2, 2021 at 9:37 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Sun, May 2, 2021 at 9:04 PM Tom Lane wrote:
> >> - state.in_quotes = false;
> >>
> >> This change seems wrong/unsafe too.
>
> > It seems OK, because this pat
On Sun, May 2, 2021 at 9:17 PM Zhihong Yu wrote:
> One minor comment:
> + /* iterate to the closing quotes or end of the string*/
>
> closing quotes -> closing quote
Yep, I've missed the third place to change from plural to single form :)
--
Regards,
Ale
quotes -> closing quote
>
> + /* or else ƒtsvector() will raise an error */
>
> The character before tsvector() seems to be special.
Thank you for catching. Fixed in v3.
--
Regards,
Alexander Korotkov
On Sun, May 2, 2021 at 9:04 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Ooops, I've included this by oversight. The next revision is attached.
> > Anything besides that?
>
> Some quick eyeball review:
>
> +/* Everything is quotes is
On Sun, May 2, 2021 at 8:52 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > It seems there is another bug with phrase search and query parsing.
> > It seems to me that since 0c4f355c6a websearch_to_tsquery() should
> > just parse text in quotes as a single token. Be
0c4f355c6a websearch_to_tsquery() should
just parse text in quotes as a single token. Besides fixing this bug,
it simplifies the code.
Trying to fix this bug before 0c4f355c6a doesn't seem to worth the efforts.
I propose to push the attached patch to v14. Objections?
--
Regards,
Alexan
to an elog or assert or just removed.
>
> Is there a reason why we can't make them all three strict or all not
> strict? (Obviously, it doesn't matter for multirange_constructor0.) Is
> the fact that multirange_constructor2 is variadic the issue? Maybe at
> least some more comments would be helpful.
Thank you for noticing. I'll take care of it today.
--
Regards,
Alexander Korotkov
hat both queries
> should return the same result, but the second one misses the shot and
> is corrected as you say. So, applied.
>
> My apologies for the delay.
My apologies for missing this. And thank you for taking care!
--
Regards,
Alexander Korotkov
, there is no partial update functionality for the on-disk
> format. Although there is work going on to optimize this in case when
> jsonb is big enough to be put into a toast table (partial toast
> decompression thread, or bytea appendable toast).
+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 alignment
ttribute. 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
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
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 clan
d 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
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
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 compilati
self looks good for me. I'm
going to push this if no objections.
--
Regards,
Alexander Korotkov
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
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 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
> >
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
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
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 backpat
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.
Th
sed 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
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 this is wrong.
T
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
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
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. I've pr
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 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 wonder
nging 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 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 it's eval
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
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
patch, but it wouldn't be
fair to completely throw it away. It still might be useful for
LSE-disabled builds.
--
Regards,
Alexander Korotkov
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
&g
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 suites. T
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 seem to
ross 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
erent 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
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
> &
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
> advance.
>
&
9.1606530957%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
dest. It's probably because he
runs the tests with a low number of clients.
--
Regards,
Alexander Korotkov
e
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
etween 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
> effect there.
>
> Bottom line is that these
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 looking a
e 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
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 SpinLockAcquir
401 - 500 of 1182 matches
Mail list logo
