Hi, Anton!
On Mon, Dec 4, 2023 at 3:50 AM Anton A. Melnikov
wrote:
> Thanks for remarks!
>
> On 28.11.2023 21:34, Alexander Korotkov wrote:
> > After examining the second patch
> > ("v2-0001-Add-restartpoint-stats.patch"), it appears that adding
> &
On Fri, Dec 22, 2023 at 8:53 AM Andrei Lepikhov
wrote:
> On 21/12/2023 12:10, Alexander Korotkov wrote:
> > I took a closer look at the patch in [9]. I should drop my argument
> > about breaking the model, because add_path() already considers other
> > aspects than just c
ull
match of group-by output to the required order.
--
Regards,
Alexander Korotkov
On Thu, Dec 21, 2023 at 10:41 AM Andrei Lepikhov
wrote:
>
> On 18/12/2023 15:29, Alexander Korotkov wrote:
> > Also, there is a set of patches [7], [8], and [9], which makes the
> > optimizer consider path selectivity as long as path costs during the
> > path selection.
836-5d61-a4e0-af82-5821a2a1f0a7%40enterprisedb.com
--
Regards,
Alexander Korotkov
did some investigations.
AdjustToFullTransactionId() uses TransamVariables->nextXid to convert
TransactionId into FullTransactionId. However,
ProcArrayApplyRecoveryInfo() first checks two phase transactions then
updates TransamVariables->nextXid. Please, see the draft patch
fixing this
you can. I will probably provide a more polished version
meanwhile.
--
Regards,
Alexander Korotkov
On Mon, Dec 11, 2023 at 5:56 PM Alexander Korotkov wrote:
> > BTW, do we really need to keep around the BTScanOpaqueData.firstPage
> > field? Why can't the call to _bt_readpage from _bt_first (and from
> > _bt_endpoint) just pass "firstPage=true" as a simple argument?
al to fix the problem. Instead
of relying on _bt_first(), let's rely on the first matched item on the
page. Once it's found, we may skip scan keys required for the opposite
direction. What do you think?
--
Regards,
Alexander Korotkov
On Fri, Dec 8, 2023 at 8:30 PM Alexander Korotkov wrote:
> On Wed, Dec 6, 2023 at 6:05 AM Alexander Korotkov
> wrote:
> > On Wed, Dec 6, 2023 at 3:46 AM Peter Geoghegan wrote:
> > > On Tue, Dec 5, 2023 at 4:41 PM Peter Geoghegan wrote:
> > > > "In gen
On Wed, Dec 6, 2023 at 6:05 AM Alexander Korotkov wrote:
> On Wed, Dec 6, 2023 at 3:46 AM Peter Geoghegan wrote:
> > On Tue, Dec 5, 2023 at 4:41 PM Peter Geoghegan wrote:
> > > "In general, when inequality keys are present, the initial-positioning
> > > code
Is it the fixes posted
in [1]. If so it's very surprising for me they are reducing the
memory footprint size.
Links.
1.
https://www.postgresql.org/message-id/CAPpHfdtLgCryACcrmLv=Koq9rAB3=tr5y9d84dggvuhscvj...@mail.gmail.com
--
Regards,
Alexander Korotkov
> SELECT pg_waitlsn_no_wait(‘LSN’);
Nice, because simplicity. But only safe if called within the simple
query containing nothing else. Validating this from the function
kills the simplicity.
--
Regards,
Alexander Korotkov
On Fri, Dec 8, 2023 at 11:20 AM Kartyshov Ivan
wrote:
>
> On 2023-11-27 03:08, Alexander Korotkov wrote:
> > I've retried my case with v6 and it doesn't fail anymore. But I
> > wonder how safe it is to reset xmin within the user-visible function?
> > We have no gua
ren't removed when they have arguments of different types.
Please give me a bit of time to figure out how to workaround this.
--
Regards,
Alexander Korotkov
Hi, Alexander!
On Tue, Nov 7, 2023 at 3:00 PM Alexander Lakhin wrote:
>
> 07.11.2023 14:38, Alexander Korotkov wrote:
> > Hi, Alexander.
> >
> > On Tue, Nov 7, 2023 at 1:00 PM Alexander Lakhin wrote:
> >> It looks like the v2 patch doesn't fix the original i
Hi, Alexander!
On Mon, Nov 27, 2023 at 5:11 PM Alexander Pyhalov
wrote:
> Alexander Korotkov писал(а) 2023-11-27 03:49:
>
> > Thank you for the revision.
> >
> > I've revised the patch myself. I've replaced StringInfo with
> > additional conds into a list of st
On Thu, Nov 30, 2023 at 10:29 AM Pavel Borisov wrote:
> Agree. The fix is attached.
What an oversight.
Thank you, pushed!
--
Regards,
Alexander Korotkov
greSQL community.
Please consider expanding the documentation to include detailed
explanations of the new statistics and their implications in various
scenarios.
--
Regards,
Alexander Korotkov
eikki, thank you for catching this.
This mess with file names formats already lasts quite long. I don't
think we should hurry unifying this as long as we're anyway going to
change that in near future.
Please, find the revised patchset with relevant comment.
--
Regards,
Alexander Korotkov
review.
--
Regards,
Alexander Korotkov
--
Regards,
Alexander Korotkov
On Mon, Nov 27, 2023 at 9:00 AM Alexander Lakhin
wrote:
> Hello Alexander,
>
> 27.11.2023 02:43, Alexander Korotkov wrote:
>
> > v61 looks good to me. I'm going to push it as long as there a
ink about the patches upthread [1].
Links
1.
https://www.postgresql.org/message-id/CAPpHfdtLgCryACcrmLv=Koq9rAB3=tr5y9d84dggvuhscvj...@mail.gmail.com
--
Regards,
Alexander Korotkov
On Fri, Nov 24, 2023 at 3:54 PM Alexander Korotkov wrote:
>
> On Thu, Nov 23, 2023 at 4:33 AM Richard Guo wrote:
> >
> > On Sun, Nov 19, 2023 at 9:17 AM Alexander Korotkov
> > wrote:
> >>
> >> It's here. New REALLOCATE_BITMAPSETS forces bitmap
sing as well as comments on
each manipulation with additional conds. Could you please add this?
--
Regards,
Alexander Korotkov
0001-postgres_fdw-add-support-for-deparsing-semi-joins-v6.patch
Description: Binary data
e query work with xmin
reset? Separate utility statement still looks like more safe option
for me.
--
Regards,
Alexander Korotkov
rk.
--
Regards,
Alexander Korotkov
e, NULL, 16);
v61 looks good to me. I'm going to push it as long as there are no objections.
--
Regards,
Alexander Korotkov
On Sat, Nov 25, 2023 at 10:45 PM Andrei Zubkov wrote:
> On Sat, 2023-11-25 at 02:45 +0200, Alexander Korotkov wrote:
>
> > I've reviewed this patch.
>
> Thank you very much for your review.
>
> > I think the design was well-discussed in this thread. Implementatio
On Fri, Nov 24, 2023 at 5:18 PM Mark Dilger
wrote:
> > On Nov 23, 2023, at 4:42 AM, Alexander Korotkov
> > wrote:
>
>
> > 0006-Generalize-table-AM-API-for-INSERT-.-ON-CONFLICT-v1.patch
> >
> > Provides a new table AM API method to encapsulate the whole INSE
On Sat, Nov 25, 2023 at 11:14 AM Egor Rogov wrote:
>
> Hi Alexander,
>
> On 25.11.2023 02:06, Alexander Korotkov wrote:
> >
> > In conclusion of all of the above, I decided to revise the patch and
> > show the bounds histogram as it's stored in pg_stat
On Sat, Nov 25, 2023 at 10:58 AM jian he wrote:
> On Sat, Nov 25, 2023 at 7:06 AM Alexander Korotkov
> wrote:
> >
> > Hi!
> > Additionally, I found that the current patch can't handle infinite
> > range bounds and discards information about inclusiveness of r
On Sat, Nov 25, 2023 at 1:10 PM Alena Rybakina
wrote:
> On 25.11.2023 04:13, Alexander Korotkov wrote:
>
> It seems to me there is a confusion. I didn't mean we need to move
> conversion of OR-expressions to ANY into choose_bitmap_and() function
> or anything like this. My id
y do we use home-grown code for resolving
hash-collisions. You can just define custom hash and match functions
in HASHCTL. Even if we need to avoid repeated JumbleExpr calls, we
still can save pre-calculated hash value into hash entry and use
custom hash and match. This doesn't imply us to write our own
collision-resolving code.
--
Regards,
Alexander Korotkov
nversion of OR-expressions to ANY wouldn't affect the generation of
bitmap paths.
Links
1.
https://www.postgresql.org/message-id/CAPpHfduJtO0s9E=shutzrcd88bh0eik0unog1_q3xbf2wlm...@mail.gmail.com
--
Regards,
Alexander Korotkov
e operations.
I think the design was well-discussed in this thread. Implementation
also looks good to me. I've just slightly revised the commit
messages.
I'd going to push this patchset if no objections.
--
Regards,
Alexander Korotkov
0002-Track-statement-entry-timestamp-in-contrib-pg_st-v27.p
ion of new columns to
the documentation of pg_user_mapping table. I've fixed that by moving
them to the documentation of pg_stats view.
Also, I've extracted the new comment in pg_statistic.h into a separate patch.
I'm going to push this if there are no objections.
--
Regards,
Alexander
On Thu, Nov 23, 2023 at 4:33 AM Richard Guo wrote:
>
> On Sun, Nov 19, 2023 at 9:17 AM Alexander Korotkov
> wrote:
>>
>> It's here. New REALLOCATE_BITMAPSETS forces bitmapset reallocation on
>> each modification.
>
>
> +1 to the idea of introducing a reall
On Wed, Nov 15, 2023 at 5:07 PM Alexander Korotkov wrote:
>
> On Wed, Nov 15, 2023 at 8:02 AM Andres Freund wrote:
> > The kinda because there are callers to bms_(add|del)_members() that pass the
> > same bms as a and b, which only works if the reallocation happens "lat
as the "Delete relid
> without substitution" path has the same issue. With that also copying and all
> the "reusing" bms* functions always reallocating, the tests pass - kinda.
>
>
> The kinda because there are callers to bms_(add|del)_members() that pass the
> same bms as a and b, which only works if the reallocation happens "late".
+1,
Neat idea. I'm willing to work on this. Will propose the patch soon.
--
Regards,
Alexander Korotkov
On Wed, Nov 15, 2023 at 8:04 AM Andres Freund wrote:
>
> On 2023-11-14 14:42:13 +0200, Alexander Korotkov wrote:
> > It's possibly dumb option, but what about just removing the assert?
>
> That's not at all an option - the in-place bms_* functions can free their
> input.
hese places.
This looks better to me. However, I'm not sure what the overhead
would be? How much would it increase the memory footprint?
It's possibly dumb option, but what about just removing the assert?
--
Regards,
Alexander Korotkov
That's a bug in the patch. Thank you for cathing it. It should start
calculation from latestCompletedXid + 1, not InvalidTransactionId.
Please, check the revised patch.
--
Regards,
Alexander Korotkov
0001-Fix-false-reports-in-pg_visibility-v3.patch
Description: Binary data
; segno <= 0x1);
return snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir,
(unsigned int) segno);
}
}
As I now get, snprintf() wouldn't just truncate the high signs, instead it
will use more characters. But I think assertions are useful anyway.
--
Regards,
Alexander Korotkov
On Mon, Nov 6, 2023 at 3:42 PM Pavel Borisov wrote:
>
> On Mon, 6 Nov 2023 at 17:07, Alexander Korotkov wrote:
> > On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev
> > wrote:
> > > PFE the corrected patchset v58.
> >
> > I'd like to revive this thread.
umbers. Thus, I think test/modules/test_slru is a good
place to give high page numbers a good test.
--
Regards,
Alexander Korotkov
slots.
Surely these would significantly sacrifice accuracy. But we have to do
so in order to avoid reporting false errors.
Any thoughts?
--
Regards,
Alexander Korotkov
0001-Fix-false-reports-in-pg_visibility-v2.patch
Description: Binary data
the patch much more complicated. I'm OK to continue with a
simpler patch to handle the majority of cases. Could you please add the
cases, which can't be pushed down with the current patch, to the test suite?
Links
1.
https://www.postgresql.org/message-id/816fa8b1bc2da09a87484d1ef239a332%40postgrespro.ru
--
Regards,
Alexander Korotkov
tch shows regression [1]. The
first one (quadratic complexity of expression processing) should be
already addressed by usage of hash. The second one (planning
regression with Bitmap OR) is not yet addressed.
Links
1.
https://www.postgresql.org/message-id/CAPpHfduJtO0s9E%3DSHUTzrCD88BH0eik0UNog1_q3XBF2wLmH6g%40mail.gmail.com
--
Regards,
Alexander Korotkov
cross a range of machines, so I recommend
> just removing the test case involving a fatal exit.
Makes sense. Are you good with the attached patch?
--
Regards,
Alexander Korotkov
fix_login_trigger_test_instability.patch
Description: Binary data
ther
minor enchantments.
I think this patch is ready to go. I'm going to push it if there are
no objections.
--
Regards,
Alexander Korotkov
0001-Teach-contrib-amcheck-to-check-the-unique-constr-v18.patch
Description: Binary data
On Mon, Oct 23, 2023 at 2:00 PM Alexander Lakhin wrote:
> 23.10.2023 12:47, Alexander Korotkov wrote:
> > I think this patch makes substantial improvement to query planning.
> > It has received plenty of reviews. The code is currently in quite
> > good shape. I didn't man
On Mon, Oct 23, 2023 at 6:43 AM Andrei Lepikhov
wrote:
> On 22/10/2023 05:01, Alexander Korotkov wrote:
> > On Thu, Oct 19, 2023 at 6:16 AM Andrei Lepikhov
> > wrote:
> >> On 19/10/2023 01:50, Alexander Korotkov wrote:
> >>> This query took 3778.43
On Thu, Oct 19, 2023 at 6:16 AM Andrei Lepikhov
wrote:
> On 19/10/2023 01:50, Alexander Korotkov wrote:
> > This query took 3778.432 ms with self-join removal disabled, and
> > 3756.009 ms with self-join removal enabled. So, no measurable
> > overhead. Similar to the h
On Mon, Oct 16, 2023 at 11:28 AM Andrei Lepikhov
wrote:
> On 12/10/2023 18:32, Alexander Korotkov wrote:
> > On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
> > wrote:
> >> On 4/10/2023 14:34, Alexander Korotkov wrote:
> >>> > Relid replacement machinery
an independent patch then.
Thank you for catching it. Please, post this.
--
Regards,
Alexander Korotkov
On Mon, Oct 16, 2023 at 4:00 AM Michael Paquier wrote:
> On Mon, Oct 16, 2023 at 02:47:03AM +0300, Alexander Korotkov wrote:
> > The attached revision fixes test failures spotted by
> > commitfest.cputube.org. Also, perl scripts passed perltidy.
>
> Still you've missed a
On Sat, Oct 14, 2023 at 2:10 AM Alexander Korotkov wrote:
> On Fri, Oct 13, 2023 at 11:26 AM Alexander Korotkov
> wrote:
> > On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> > > On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> > > wrote:
> > > &
an restart this work.
> The first thing here (after rebase, of course) is to figure out and
> implement in the cost model cases of effectiveness when asymmetric join
> would give significant performance.
Great! I'm looking forward to the revised patch.
--
Regards,
Alexander Korotkov
Hi!
On Wed, Oct 4, 2023 at 1:22 PM Alexander Korotkov wrote:
> I see you're concentrating on the procedural version of this feature. But
> when you're calling a procedure within a normal SQL statement, the executor
> gets a snapshot and holds it until the procedure finishes. In
stance, if the
nested loop join is cheaper than the hash join, but the hash join
generates a common hash map of table A, we don't drop hash join
immediately from the consideration and leave it to see how it could
help join other partitions. What do you think?
--
Regards,
Alexander Korotkov
garding the GUC parameter, I don't see we need a limit. It's not
yet clear whether a small number or a large number of OR clauses are
more favorable for transformation. I propose to have just a boolean
enable_or_transformation GUC.
Links
1.
https://www.postgresql.org/message-id/6b97b517-f36a-f0c6-3b3a-0cf8cfba220c%40yandex.ru
2.
https://www.postgresql.org/message-id/938d82e1-98df-6553-334c-9db7c4e288ae%40yandex.ru
--
Regards,
Alexander Korotkov
On Fri, Oct 13, 2023 at 11:26 AM Alexander Korotkov
wrote:
> On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> > On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> > wrote:
> > > On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
> >
> > > > Does
On Fri, Oct 13, 2023 at 4:18 AM Robert Haas wrote:
> On Thu, Oct 12, 2023 at 6:54 PM Alexander Korotkov
> wrote:
> > On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
>
> > > Doesn't that mean that if you create the first login trigger in a
> > > databa
On Thu, Oct 12, 2023 at 8:35 PM Robert Haas wrote:
> On Tue, Oct 10, 2023 at 3:43 PM Alexander Korotkov
> wrote:
> > Yep, in v43 it worked that way. One transaction has to wait for
> > another finishing update of pg_database tuple, then fails. This is
> > obvi
On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
wrote:
> On 4/10/2023 14:34, Alexander Korotkov wrote:
> > > Relid replacement machinery is the most contradictory code here. We used
> > > a utilitarian approach and implemented a simplistic variant.
> >
> >
Hi, Robert!
Thank you for your feedback.
On Tue, Oct 10, 2023 at 5:51 PM Robert Haas wrote:
>
> On Mon, Oct 9, 2023 at 10:11 AM Alexander Korotkov
> wrote:
> > * Hold lock during setting of pg_database.dathasloginevt flag (v32
> > version actually didn't prevent ra
Hi!
Thank you for the review.
On Tue, Oct 10, 2023 at 7:37 PM Andres Freund wrote:
> On 2023-10-10 08:18:46 +0300, Alexander Korotkov wrote:
> > @@ -968,7 +969,7 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
> >
> > if (!get_db_info(
On Mon, Oct 9, 2023 at 11:58 PM Andres Freund wrote:
> On 2023-10-09 17:11:25 +0300, Alexander Korotkov wrote:
> > This version should be good and has no overhead. Any thoughts?
>
> I think you forgot to attach the patch?
That's it!
--
Regards,
Alexander Korotkov
0001-Ad
Hi!
On Tue, Oct 3, 2023 at 8:35 PM Alexander Korotkov wrote:
> Thank you for the interesting ideas. I'd like to try to revive the
> version with the flag in pg_database. Will use other ideas as backup
> if no success.
I've revived the patch version with pg_database.dathasloginevt fla
On Fri, Oct 6, 2023 at 9:59 PM Pavel Borisov wrote:
> On Fri, 6 Oct 2023 at 22:44, Konstantin Knizhnik wrote:
> >
> >
> > On 04/10/2023 3:00 am, Alexander Korotkov wrote:
> > > On Wed, Oct 4, 2023 at 12:59 AM Pavel Borisov
> > > wrote:
> > >>
is the same.
> +* result is the same.
> */
> Assert(!requiredMatchedByPrecheck ||
>passes_quals == _bt_checkkeys(scan, itup, indnatts, dir,
Fixed, thanks!
--
Regards,
Alexander Korotkov
. This code will start the waiting cycle even if the
LSN is already achieved. Surely this cycle will end soon because it
rechecks LSN value each 100 ms. But anyway, I think there should be
another check after AddWaitedLSN() for the sake of consistency.
--
Regards,
Alexander Korotkov
Hi!
On Wed, Oct 4, 2023 at 9:56 AM Andrei Lepikhov
wrote:
> On 4/10/2023 07:12, Alexander Korotkov wrote:
> > On Tue, Sep 12, 2023 at 4:58 PM Andrey Lepikhov
> > wrote:
> >> On 5/7/2023 21:28, Andrey Lepikhov wrote:
> >>> During the significant code revi
ps://www.postgresql.org/message-id/flat/830269.1656693747%40sss.pgh.pa.us
--
Regards,
Alexander Korotkov
On Wed, Oct 4, 2023 at 12:59 AM Pavel Borisov wrote:
> I've looked through the patch v8. I think it's good enough to be
> pushed if Peter has no objections.
Thank you, Pavel.
I'll push this if there are no objections.
--
Regards,
Alexander Korotkov
cache in front of something
> that's basically a full-table scan.
Thank you for the interesting ideas. I'd like to try to revive the
version with the flag in pg_database. Will use other ideas as backup
if no success.
--
Regards,
Alexander Korotkov
On Fri, Sep 29, 2023 at 1:15 PM Daniel Gustafsson wrote:
> > On 28 Sep 2023, at 23:50, Alexander Korotkov wrote:
>
> > I don't think I can reproduce the performance regression pointed out
> > by Pavel Stehule [1].
>
> > I can't confirm the measurable overhead.
Hi, Peter.
On Fri, Sep 29, 2023 at 4:57 AM Peter Geoghegan wrote:
> On Fri, Sep 22, 2023 at 7:24 AM Alexander Korotkov
> wrote:
> > The thing is that NULLs could appear in the middle of matching values.
> >
> > # WITH t (a, b) AS (VALUES ('a', 'b'), ('a', NULL), ('b
Hi, Daniel!
On Mon, Sep 25, 2023 at 3:42 PM Daniel Gustafsson wrote:
> > On 25 Sep 2023, at 11:13, Alexander Korotkov wrote:
>
> > I'd like to do a short summary of
> > design issues on this thread.
>
> Thanks for summarizing this long thread!
>
> > the
On Thu, Sep 28, 2023 at 5:21 AM Peter Geoghegan wrote:
> On Wed, Sep 27, 2023 at 9:41 AM Alexander Korotkov
> wrote:
> > Fixed typo inficating => indicating as pointed by Pavel.
> > Peter, what do you think about the current shape of the patch?
>
> I'll try to get t
od() is heavily
used in our codebase. So, changing its signature would be invasive.
Could we invent getBaseTypeAndTypmodExtended() (ideas for a better
name?) that does all the job and supports "bool missing_ok" argument,
and have getBaseTypeAndTypmod() as a wrapper with the same signature?
--
Regards,
Alexander Korotkov
On Mon, Sep 25, 2023 at 1:18 PM Alexander Korotkov
wrote:
> On Mon, Sep 25, 2023 at 12:58 PM Pavel Borisov
> wrote:
> > One more doubt about naming. Calling function
> > _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
> > ScanDirection dir,
, indnatts, dir,
> , false);
> looks little bit misleading because of coincidence of names of 5 and 6
> arguments.
I've added the comment clarifying this argument usage.
--
Regards,
Alexander Korotkov
0001-Skip-checking-of-scan-keys-required-for-direction-v6.patch
Description: Binary data
-4755-dcfc-2d24-b12bcfe4467f%40sigaev.ru
11.
https://www.postgresql.org/message-id/CA%2BTgmoZv9f1s797tihx-zXQN4AE4ZFBV5C0K%3DzngbgNu3xNNkg%40mail.gmail.com
12.
https://www.postgresql.org/message-id/20220312024652.lvgehszwke4hhove%40alap3.anarazel.de
--
Regards,
Alexander Korotkov
d better not pass _bt_readpage an offset number
> for a tuple with "foo" value 4. If that is ever allowed then
> _bt_checkkeys will terminate the scan immediately, leading to wrong
> answers. All because _bt_checkkeys can't tell if 4 comes before 5 or
> comes after 5 -- it only ha
On Wed, Sep 20, 2023 at 5:07 PM Alexander Korotkov wrote:
> On Tue, Sep 19, 2023 at 1:48 AM Peter Geoghegan wrote:
> This also makes sense. I've rephrased the comment.
The revised patch is attached. It contains better comments and the
commit message. Peter, could you please check if
Hi, Peter!
Thank you for your interest in this patch.
On Tue, Sep 19, 2023 at 1:48 AM Peter Geoghegan wrote:
>
> On Thu, Sep 14, 2023 at 3:23 AM Alexander Korotkov
> wrote:
> > The attached patch allows Postgres to skip scan keys required for
> > directional scans
exact
> search.
>
Neat optimization! But I wonder if we could do even better. The attached
patch allows Postgres to skip scan keys required for directional scans
(even when other keys are present in the scan). I'll soon post the testing
results and a more polished version of this patc
eing.
I'm looking forward to continuing working with you on this subject for v17.
--
Regards,
Alexander Korotkov
k1Fv63c6txwMAkzxFMGMf29jqa9uU_CdQ%40mail.gmail.com
2.
https://www.postgresql.org/message-id/CAPpHfdu6roOVEUsV9TWNdQ%3DTZCrNEEwJM62EQiKULUyjpERhtg%40mail.gmail.com
--
Regards,
Alexander Korotkov
On Fri, Apr 28, 2023 at 2:30 AM Alexander Korotkov wrote:
> Additionally, I think if we start recording role OID, then we need a
> full set of management clauses for each individual option ownership.
> Otherwise, we would leave this new role OID without necessarily
> managemen
explicit revoke recorder in the system
catalog. That behavior will be current if we understand the default
options as separate material things (as it is today), but not part of
the setter role.
--
Regards,
Alexander Korotkov
.On Thu, Apr 27, 2023 at 9:55 PM Nathan Bossart
wrote:
> On Thu, Apr 27, 2023 at 09:53:23PM +0300, Alexander Korotkov wrote:
> > Thanks to everybody for catching and investigating this.
> > Nathan, I'd like to push it myself. I'm also going to check the code
> > for simil
d investigating this.
Nathan, I'd like to push it myself. I'm also going to check the code
for similar errors.
--
Regards,
Alexander Korotkov
On Sun, Apr 23, 2023 at 3:36 PM Daniel Gustafsson wrote:
> > On 23 Apr 2023, at 13:59, Alexander Korotkov wrote:
> >
> > On Fri, Apr 21, 2023 at 2:21 PM Pavel Borisov
> > wrote:
> >>> On Fri, 21 Apr 2023 at 15:14, Daniel Gustafsson wrote:
> >>>
nto one but as they fix completely unrelated
> things, I think a better way to commit them separately.)
I wonder if we should backpatch this. On the one hand, this is not
critical, and we may skip backpatching. On the other hand,
backpatching will evade unnecessary code differences between major
versions and potentially simplify further backpatching.
I would prefer backpathing. Other opinions?
--
Regards,
Alexander Korotkov
ou review, revisions and rebase.
We'll reconsider this once v17 is branched.
--
Regards,
Alexander Korotkov
On Sun, Apr 2, 2023 at 3:47 AM Andres Freund wrote:
> On 2023-04-02 03:37:19 +0300, Alexander Korotkov wrote:
> > On Sat, Apr 1, 2023 at 8:21 AM Andres Freund wrote:
> > > Given that the in-tree state has been broken for a week, I think it
> > > probably
> >
.Hi!
On Sat, Apr 1, 2023 at 8:21 AM Andres Freund wrote:
> On 2023-03-31 16:57:41 +0300, Alexander Korotkov wrote:
> > On Wed, Mar 29, 2023 at 8:34 PM Alexander Korotkov
> > wrote:
> > > On Mon, Mar 27, 2023 at 1:49 PM Alexander Korotkov
> > > wrote:
> &
On Wed, Mar 29, 2023 at 8:34 PM Alexander Korotkov wrote:
> On Mon, Mar 27, 2023 at 1:49 PM Alexander Korotkov
> wrote:
> > On Fri, Mar 24, 2023 at 3:39 AM Andres Freund wrote:
> > > On 2023-03-23 23:24:19 +0300, Alexander Korotkov wrote:
> > > > On Thu, Mar
201 - 300 of 1178 matches
Mail list logo
