n near 100% coverage for what it's costing in runtime.
I don't think there is any idea behind this. Seems to be just oversight.
Do you like me to write a patch improving coverage here?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote:
> Alexander Korotkov writes:
> >> On Wed, Apr 17, 2019 at 8:43 PM Tom Lane wrote:
> >>> Yeah, I'd noticed that one too :-(. I think the whole jsonpath patch
> >>> needs a sweep to bring its error messages into
On Thu, Nov 29, 2018 at 3:44 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Fri, Aug 24, 2018 at 5:53 PM Alexander Korotkov
> > wrote:
> >
> > Given I've no feedback on this idea yet, I'll try to implement a PoC
> > patch for that. It doesn't l
Hi!
Thank you for your review!
On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote:
> Alexander Korotkov writes:
> RETURN_ERROR(ereport(ERROR,
> (errcode(ERRCODE_JSON_ARRAY_NOT_FOUND),
>
thout backtracking, yy_nxt is 6336
> (there is no yy_transition). I'd say that's a large enough difference
> that we'd want the smaller representation if it makes little
> difference in performance.
Did I understand correctly that you've tried the same version of
jsonpath_scan.l with different f
On Wed, Apr 17, 2019 at 11:14 PM Alexander Korotkov
wrote:
> On Wed, Apr 17, 2019 at 8:43 PM Tom Lane wrote:
> > John Naylor writes:
> > > Attached is a patch to fix some minor issues:
> > > -misspelling of an error message
> >
> > Yeah, I'd noticed that o
2 -- it might give a small performance boost to the
> > scanner.
>
> I doubt it's worth the trouble, per above.
>
> Patch LGTM, pushed.
Thank you for pushing this!
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
pages between them, they are candidates to have missing
parent downlinks. The patch is attached.
With this patch amcheck could successfully detect corruption for our
customer, which unpatched amcheck couldn't find.
Opinions?
--
Alexander Korotkov
Postgres Professional: http
On Wed, Apr 10, 2019 at 8:32 PM Andres Freund wrote:
> On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote:
> > Your explanation of existing limitations looks very good and
> > convincing. But I think there is one you didn't mention. We require
> > new table AMs
On Tue, Apr 9, 2019 at 7:16 PM Tomas Vondra
wrote:
>
> On Sun, Apr 07, 2019 at 03:03:58AM +0300, Alexander Korotkov wrote:
> >On Sun, Apr 7, 2019 at 2:37 AM Tom Lane wrote:
> >> Alexander Korotkov writes:
> >> > Thus, contents of unused function makes test fail
On Wed, Apr 10, 2019 at 8:32 PM Andres Freund wrote:
> On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote:
> > Your explanation of existing limitations looks very good and
> > convincing. But I think there is one you didn't mention. We require
> > new table AMs
able-AM API flexible enough to implement
both. I can imagine we have proper encapsulation here bringing more
interaction with indexes to the table AM side.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Apr 7, 2019 at 2:37 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > Thus, contents of unused function makes test fail or pass. So far, it
> > looks like a compiler bug. Any thoughts?
>
> Yeah :-(. The fact that we've not seen a similar failure on any ot
On Wed, Apr 3, 2019 at 11:03 PM Andres Freund wrote:
>
> On 2019-03-30 18:25:12 +0300, Alexander Korotkov wrote:
> > I'm going to push there 3 attached patches for jsonpath.
>
> I noticed that
> https://commitfest.postgresql.org/22/1472/
> https://commitfest.postgresql.
On Fri, Mar 29, 2019 at 4:15 PM Alexander Korotkov
wrote:
> On Thu, Mar 28, 2019 at 7:43 PM Andrew Dunstan
> wrote:
> > On 3/28/19 9:50 AM, Tom Lane wrote:
> > > Andres Freund writes:
> > >> On March 28, 2019 9:31:14 AM EDT, Tom Lane wrote:
> > >&g
commit 550b9d26f.
Hmm... 550b9d26f just makes jsonpath_gram.y and jsonpath_scan.l
compile at once. I've re-read this commit and didn't find anything
suspicious.
I've asked Andrew for access to jacana in order to investigate this myself.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
esn't seem to be related to
our issue.
1.
https://www.postgresql.org/message-id/CAPpHfdsgyPKbaqOsJ4tyC97Ybpm69eGLHzBGLKYXsfJi%3Dc-fjA%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Mar 28, 2019 at 3:25 PM Andrew Dunstan
wrote:
> On 3/28/19 5:38 AM, Alexander Korotkov wrote:
> > On Thu, Mar 28, 2019 at 5:55 AM Andrew Dunstan
> > wrote:
> >> On 3/27/19 9:48 AM, Tom Lane wrote:
> >>> Alexander Korotkov writes:
> >>>&
On Thu, Mar 28, 2019 at 5:55 AM Andrew Dunstan
wrote:
> On 3/27/19 9:48 AM, Tom Lane wrote:
> > Alexander Korotkov writes:
> >> Still no reproduction.
> > Annoying, but it's probably not worth expending more effort on
> > right now. I wonder whether that bu
On Wed, Mar 27, 2019 at 4:49 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Still no reproduction.
>
> Annoying, but it's probably not worth expending more effort on
> right now. I wonder whether that buildfarm animal can be upgraded
> to capture core dump s
On Tue, Mar 26, 2019 at 6:06 PM Alexander Korotkov
wrote:
> On Tue, Mar 26, 2019 at 5:32 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > Got access to that buildfarm animal thanks to Tom Turelinckx. Now
> > > running check-world in a loop on the same
On Tue, Mar 26, 2019 at 5:32 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Got access to that buildfarm animal thanks to Tom Turelinckx. Now
> > running check-world in a loop on the same commit hash with same build
> > options. Error wasn't triggered yet.
>
On Sun, Mar 24, 2019 at 9:09 PM Alexander Korotkov
wrote:
> On Sun, Mar 24, 2019 at 7:45 PM Andres Freund wrote:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper=2019-03-23%2013%3A01%3A28
> >
> > 2019-03-23 14:28:31.147 CET [18056:45] pg_regress/jso
t quite right... Note this appears to be 32bit sparc.
Thank you for pointing. Will investigate.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Mar 23, 2019 at 11:43 AM Alexander Korotkov
wrote:
> On Fri, Mar 22, 2019 at 11:05 AM Alexander Korotkov
> wrote:
> > On Fri, Mar 22, 2019 at 12:06 AM Alvaro Herrera
> > wrote:
> > > On 2019-Mar-21, Alexander Korotkov wrote:
> > >
> > > >
On Fri, Mar 22, 2019 at 11:05 AM Alexander Korotkov
wrote:
> On Fri, Mar 22, 2019 at 12:06 AM Alvaro Herrera
> wrote:
> > On 2019-Mar-21, Alexander Korotkov wrote:
> >
> > > However, I think this still can be backpatched correctly. We can
> > > determi
On Fri, Mar 22, 2019 at 5:38 AM John Naylor wrote:
> On Thu, Mar 21, 2019 at 9:59 PM Alexander Korotkov
> wrote:
> > Attaches patches improving jsonpath parser. First one introduces
> > cosmetic changes, while second gets rid of backtracking. I'm also
> > planning t
On Fri, Mar 22, 2019 at 12:06 AM Alvaro Herrera
wrote:
> On 2019-Mar-21, Alexander Korotkov wrote:
>
> > However, I think this still can be backpatched correctly. We can
> > determine whether xlog record data contains deleteXid by its size.
> > See the attached patch.
On Thu, Mar 21, 2019 at 9:26 PM Simon Riggs wrote:
> On Thu, 13 Dec 2018 at 14:48, Alexander Korotkov wrote:
>> On Thu, Dec 13, 2018 at 10:46 PM Andres Freund wrote:
>> > On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote:
>> > > It doesn't mater, because
On Tue, Mar 19, 2019 at 8:10 PM Alexander Korotkov
wrote:
> On Sun, Mar 17, 2019 at 6:03 PM Tom Lane wrote:
> > Andrew Dunstan writes:
> > > Why are we installing the jsonpath_gram.h file? It's not going to be
> > > used by anything else, is it? TBH, I
On Tue, Mar 19, 2019 at 6:48 PM Robert Haas wrote:
> On Mon, Mar 18, 2019 at 12:53 PM Alexander Korotkov
> wrote:
> > I've discovered bug, when vacuum full fails with error, because it
> > couldn't find toast chunks deleted by itself. That happens because
> > clust
dows machine. There would be
further patches rearranging jsonpath_gram.y and jsonpath_scan.l.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
0001-get-rid-of-jsonpath_gram_h.patch
Description: Binary data
On Tue, Mar 19, 2019 at 12:23 PM John Naylor
wrote:
> On Sun, Feb 24, 2019 at 5:03 PM Alexander Korotkov
> wrote:
> > On Wed, Jan 30, 2019 at 5:28 AM Andres Freund wrote:
> > > Why -CF, and why is -p repeated?
> >
> > BTW, for our SQL grammar we have
> &
On Mon, Mar 18, 2019 at 11:23 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Mar 18, 2019 at 10:08 PM Tom Lane wrote:
> >> Just another minor bitch about this patch: jsonpath_scan.l has introduced
> >> a typedef called "keyword". This is
s used as
> a field or variable name. Please rename that typedef to something less
> generic.
Ooops... I propose to rename it to KeyWord, which is already
typedef'ed in formatting.c. See the attached patch. Is it OK?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The
, when it's called from
rebuild_relation(). Actually, it's not something I'm proposing to
commit or even review, it might be just some start point for thoughts.
Any ideas?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
> On 3/17/19 1:02 PM, Alexander Korotkov wrote:
> >
> > Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
>
> I just used "USING gin(col)" so jsonb_ops.
I see. So, jsonb_ops extracts
On Sun, Mar 17, 2019 at 8:00 PM Jonathan S. Katz wrote:
> On 3/17/19 12:55 PM, Alexander Korotkov wrote:
> >
> >> However, when I did something a little more complex, like the below:
> >>
> >> SELECT count(*)
> >> FROM news_feed
> >> WHERE
can understand where GIN will work very well with JSON path + their data
> and not be surprised when other types of JSON path queries are
> performing on par with a sequential scan (or worse than a parallel seq
> scan).
Good point. Will do.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
I see that it's #including before postgres.h,
> which is a no-no. So that whole area needs more review anyway.
Yeah, I didn't review this part of patch carefully enough (and it
seems that other reviewers too). I'm going to write a patch revising
this part in next couple of day
s good to me. Pushed, thanks.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
> output files. There are generally good reasons for every last bit
> of weirdness in those.
I've pushed a fix. I hope I didn't forget anything.
BTW, it appears that windows build scripts also needs some fixup. I'm
not very familiar with that. I would be glad if somebody review
On Sat, Mar 16, 2019 at 9:39 PM Pavel Stehule wrote:
> so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov
> napsal:
>>
>> On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
>> wrote:
>> > On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
>> > wro
files. There are generally good reasons for every last bit
> of weirdness in those.
Uh, I didn't check that carefully enough. Thank you for the explanation.
Will fix.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
сб, 16 мар. 2019 г., 20:52 Jeff Janes :
> On Sat, Mar 16, 2019 at 5:36 AM Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>>
>> So, pushed. Many thanks to reviewers and authors!
>>
>
> I think these files have to be cleaned up by "make m
On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
wrote:
> On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
> wrote:
> > On Wed, Mar 6, 2019 at 12:40 AM Nikita Glukhov
> > wrote:
> > > Attached 36th version of the patches.
> >
> > Thank yo for the rev
On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
wrote:
> On Wed, Mar 6, 2019 at 12:40 AM Nikita Glukhov
> wrote:
> > Attached 36th version of the patches.
>
> Thank yo for the revision!
>
> In the attached revision following changes are made:
>
> > "
On Wed, Mar 13, 2019 at 12:52 PM Tomas Vondra
wrote:
> On 3/13/19 9:15 AM, Alexander Korotkov wrote:
> > On Tue, Mar 12, 2019 at 8:15 PM Tomas Vondra
> > wrote:
> >>> 0001. Pass all keys to BRIN consistent function at once.
> >>>
> >>> I think
anging the consistent function. Not sure.
I also kind of dislike signature change based on the number of
arguments. But it's still good to let extensions use old interface if
needed. What do you think about invention new consistent method, so
that extension can implement one of them? We did similar thing
nore partial match pathkeys.
Then why bother producing them? Is it stub for further incremental
sort?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Mar 8, 2019 at 11:58 AM Alexander Korotkov
wrote:
> I made some adjustments for this patch:
> * Rename tupledesc and tructTupledesc to leafTupdesc and
> nonLeafTupdesc correspondingly. I think this makes things more clear.
> * Some improvements to docs and comments.
>
nts for this patch:
* Rename tupledesc and tructTupledesc to leafTupdesc and
nonLeafTupdesc correspondingly. I think this makes things more clear.
* Some improvements to docs and comments.
* Revise commit message.
I'm going to push this on no objections.
--
Alexander Korotkov
Postgres Professional:
e patch is interesting I'll add it to the next commitfest and label
> it as 'v13'.
As far as I understand, it's intended that user should be able to fix
wraparound in single mode. Assuming this issue may prevent user form
doing this and fix is quite trivial, should we consider backpatching
I think it's in pretty good
shape. But high level review/discussion is required.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
patch for now, and let's talk
> about the other bits first.
Works for me. We don't need to make the whole work made by this patch
to be dependent on opclass parameters. It's OK to ignore this aspect
for now and come back when opclass parameters get committed.
--
Alexander Kor
er() definitely needs comments.
* In PostgreSQL we require that index scan produce exactly same
results as sequence scan. Can we ensure this is so for
@<(point,circle) operator even in corner cases of rounding error?
* In our coding style we have function name is the separate line from
its return type.
-
out of it. So,
opclass distance function looks OK for me, assuming it's not
AM-defined function, but function used for inter-opclass
compatibility.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ot
first class citizens anymore. Have you take a look at opclass
parameters patch [1]? I think it's proper solution of this problem.
I think we should postpone this parameterization until we push opclass
parameters patch.
1.
https://www.postgresql.org/message-id/d22c3a18-31c7-1879-fc11-4c
fsets, but
there are almost none of them! So, that's just plain wrong, we never
should encourage users to do something like this.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Feb 24, 2019 at 2:44 PM Tomas Vondra
wrote:
> On 2/24/19 10:03 AM, Alexander Korotkov wrote:
> > Attached is revised version of jsonpath. Assuming that jsonpath have
> > problem places, I decided to propose partial implementation.
> > Following functionality was cut
On Sun, Feb 17, 2019 at 1:09 AM Alexander Korotkov
wrote:
>
> On Sat, Feb 16, 2019 at 11:31 PM Andres Freund wrote:
> > On February 16, 2019 11:22:32 AM PST, Alexander Korotkov
> > wrote:
> > >On Sat, Feb 16, 2019 at 8:45 AM Andres Freund
> > &g
On Sat, Feb 16, 2019 at 11:31 PM Andres Freund wrote:
> On February 16, 2019 11:22:32 AM PST, Alexander Korotkov
> wrote:
> >On Sat, Feb 16, 2019 at 8:45 AM Andres Freund
> >wrote:
> >> - SQL/JSON: jsonpath
> >>
> >> WOA: This seems
d will be resolved there. So, let's don't decide this too
early.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Jan 30, 2019 at 9:36 AM Andres Freund wrote:
> On 2019-01-30 07:34:00 +0300, Alexander Korotkov wrote:
> > Thank you for your review! Let me answer some points of your review
> > while others will be answered later.
> >
> > On Wed, Jan 30, 2019 at 5
Hi!
Thank you for your review! Let me answer some points of your review
while others will be answered later.
On Wed, Jan 30, 2019 at 5:28 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > +/*INP
On Tue, Jan 29, 2019 at 4:44 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> >> FWIW, I still think this is a terrible idea and shouldn't be merged this
> >> way. The likelihood of introducing subtle bug
On Tue, Jan 29, 2019 at 4:30 AM Alexander Korotkov
wrote:
> On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > > + /*
> > > + * It is safe to use here PG_TRY/PG_CATCH without su
On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > + /*
> > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > because
> > + * no function called inside
On Tue, Jan 29, 2019 at 4:03 AM Andres Freund wrote:
> On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote:
> > + /*
> > + * It is safe to use here PG_TRY/PG_CATCH without subtransaction
> > because
> > + * no function called inside
On Wed, Jan 23, 2019 at 8:01 AM Alexander Korotkov
wrote:
> Finally, I'm going to commit this if no objections.
BTW, I decided to postpone commit for few days. Nikita and me are
still working on better error messages.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.
On Tue, Jan 22, 2019 at 12:13 PM Oleg Bartunov wrote:
>
> On Tue, Jan 22, 2019 at 8:21 AM Alexander Korotkov
> wrote:
> >
> > The next revision is attached.
> >
> > Nikita made code and documentation improvements, renamed functions
> > from "jsonpat
On Mon, Jan 21, 2019 at 6:05 PM Oleg Bartunov wrote:
> On Mon, Jan 21, 2019 at 1:40 AM Alexander Korotkov
> wrote:
> >
> > On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov
> > wrote:
> > > I'll continue revising this patchset. Nikita, could you please
On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov
wrote:
> I'll continue revising this patchset. Nikita, could you please write
> tests for 3-argument versions of functions? Also, please answer the
> question regarding "id" property.
I've some more notes regarding fu
On Sat, Jan 19, 2019 at 2:54 AM Alexander Korotkov
wrote:
> 1) It seems that @* and @# are not going to be supported by any
> indexes. I think we should remove these operators and let users use
> functions instead.
> 2) I propose to rename @~ operator to @@. We already use @@ as
On Sat, Jan 19, 2019 at 1:32 AM Tomas Vondra
wrote:
> On 1/18/19 6:58 PM, Alexander Korotkov wrote:
> > So, it looks like we can just remove then. But I think we're very
> > likely can commit jsonpath patch to PostgreSQL 12, but I'm not sure
> > about other patches. So, h
then. But I think we're very
likely can commit jsonpath patch to PostgreSQL 12, but I'm not sure
about other patches. So, having those functions exposed to user can
be extremely useful until we have separate nodes for SQL/JSON. So, I
vote to document these functions.
--
Alexander Korotkov
keys for [1, n-1] index keys.
I've already discussed these issues with Nikita personally.
Hopefully, new version will be published soon.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
r, make sure to list yourself as a mentor and remove the
> other mentors, as appropriate).
I can confirm that I'm ready to mentor projects, where I'm listed as
potential mentor.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Dec 30, 2018 at 1:19 AM Alexander Korotkov
wrote:
> On Thu, Dec 27, 2018 at 5:46 AM Alexander Korotkov
> wrote:
> > * 0006-Remove-distance-operators-from-btree_gist-v04.patch
> >
> > I see you provide btree_gist--1.6.sql and remove btree_gist--1.2.sql.
> >
On Sat, Jan 5, 2019 at 5:21 PM Tomas Vondra
wrote:
> On 1/5/19 1:11 AM, Alexander Korotkov wrote:
> > On Tue, Dec 4, 2018 at 2:23 AM Nikita Glukhov
> > wrote:
> >> 2) We define both DCH_FF# and DCH_ff#, but we never ever use the
> >> lower-case versi
It's
probably used by some subsequent SQL/JSON-related patchset. So,
please, move it there.
5) I think each usage of PG_TRY()/PG_CATCH() deserves comment
describing why it's safe to use without subtransaction. In fact we
should just state that no function called inside performs data
modification.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
this paragraph. Does it might happen that
first right tuple is under tuple size restriction, but new pivot tuple
is beyond that restriction? If so, would we have an error because of
too long pivot tuple? If not, I think this needs to be explained
better.
--
Alexander Korotkov
Postgres Pro
On Thu, Dec 27, 2018 at 7:58 PM Andrew Dunstan
wrote:
> On 12/24/18 5:47 PM, Andrew Dunstan wrote:
> > On 12/24/18 5:25 PM, Alexander Korotkov wrote:
> >> BTW, patch for reducing isolation testing for gin predicate locking is
> >> attached. Could anybody check its e
ver, what do
you think about just long sequence of ALTER OPERATOR FAMILY commands
removing old operators and adding new operators? It would be longer,
but more predictable and easier for understanding.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Dec 25, 2018 at 4:32 AM Alexander Korotkov
wrote:
> On Tue, Dec 25, 2018 at 12:19 AM Alexander Korotkov
> wrote:
> > So, we're checking for conflict on tree root for every entry insert.
> > That's right for posting tree, but completely unneeded for entry tree.
> >
On Tue, Dec 25, 2018 at 12:19 AM Alexander Korotkov
wrote:
> So, we're checking for conflict on tree root for every entry insert.
> That's right for posting tree, but completely unneeded for entry tree.
> I'm intended to change that to lock root of only posting tree if
> nobody exp
On Tue, Dec 25, 2018 at 1:48 AM Andrew Dunstan
wrote:
> On 12/24/18 5:25 PM, Alexander Korotkov wrote:
> > On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
> > wrote:
> >> чт, 20 дек. 2018 г., 2:22 Andres Freund and...@anarazel.de:
> >>> On 2018-12-03
On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
wrote:
> чт, 20 дек. 2018 г., 2:22 Andres Freund and...@anarazel.de:
>> On 2018-12-03 16:07:40 -0800, Andres Freund wrote:
>> > As far as I can tell that increase comes laregely from the new GIN
>> > tests. C
On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
wrote:
> чт, 20 дек. 2018 г., 2:22 Andres Freund and...@anarazel.de:
>> On 2018-12-03 16:07:40 -0800, Andres Freund wrote:
>> > As far as I can tell that increase comes laregely from the new GIN
>> > tests. C
ch I got from the thread is that we
shouldn't introduce new functions exposing information, which could be
already fetched from logs. However, I think following this logic we
should remove pg_postmaster_start_time() too.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
org/message-id/CAPpHfdsKS0K8q1sJ-XyMrU%3DL%2Be6XSAOgS09NXp1bQDQts%2Bqz%2Bg%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Dec 20, 2018 at 1:41 AM Alexander Korotkov
wrote:
> Please, find attached two patches I'm going to commit: for master and
> for backpatching.
So, pushed.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Dec 18, 2018 at 2:04 AM Alexander Korotkov
wrote:
> On Mon, Dec 17, 2018 at 3:35 PM Alexander Korotkov
> wrote:
> > On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
> > wrote:
> > > On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> > > >
On Mon, Dec 17, 2018 at 3:35 PM Alexander Korotkov
wrote:
> On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
> wrote:
> > On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> > > On 2018-12-17 01:03:52 +0300, Alexander Korotkov wrote:
> > > > Sorry for
On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
wrote:
> On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> > On 2018-12-17 01:03:52 +0300, Alexander Korotkov wrote:
> > > Sorry for delay. Attached patch implements conflict handling for gist
> > > microvacuu
On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> On 2018-12-17 01:03:52 +0300, Alexander Korotkov wrote:
> > On Thu, Dec 13, 2018 at 7:28 AM Alexander Korotkov
> > wrote:
> > > On Thu, Dec 13, 2018 at 1:45 AM Andres Freund wrote:
> > > > Is there
On Thu, Dec 13, 2018 at 7:28 AM Alexander Korotkov
wrote:
> On Thu, Dec 13, 2018 at 1:45 AM Andres Freund wrote:
> > Is there any reason something like that isn't necessary for gist? If so,
> > where's that documented? If not, uh, isn't that a somewhat serious bug
> > i
On Fri, Dec 14, 2018 at 9:47 PM Andres Freund wrote:
> On 2018-12-14 21:39:48 +0300, Alexander Korotkov wrote:
> > If so, then can we just give up with that? That is before setting
> > kill_prior_tuple = true, prune corresponding heap tuples.
>
> That'd require WAL logging
ap
tuples.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Dec 13, 2018 at 10:46 PM Andres Freund wrote:
> On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote:
> > It doesn't mater, because we release all locks on every buffer at one
> > time. The unlock order can have effect on what waiter will acquire
> >
801 - 900 of 1182 matches
Mail list logo
