On Fri, Mar 22, 2024 at 12:58 AM Peter Eisentraut wrote:
> On 17.03.24 15:09, Alexander Korotkov wrote:
> > My current attempt was to commit minimal implementation as less
> > invasive as possible. A new clause for BEGIN doesn't require
> > additional keywords and doesn't
eger number of milliseconds looks
a bit weird. Could the float8 number of seconds be an option?
--
Regards,
Alexander Korotkov
t this kind of
task. However, having this functionality in core would be great.
Implementing concurrent merge/split seems quite a difficult task,
which needs careful design. It might be too hard to carry around the
syntax altogether. So, I think having basic syntax in-core is a good
step forward. But I think we need a clear notice in the documentation
about the concurrency to avoid wrong user expectations.
--
Regards,
Alexander Korotkov
On Mon, Mar 25, 2024 at 4:47 AM Richard Guo wrote:
> On Mon, Mar 25, 2024 at 10:07 AM Tom Lane wrote:
>>
>> Alexander Korotkov writes:
>> > Here goes the revised patch. I'm going to push this if there are no
>> > objections.
>>
>> Quit
On Tue, Mar 19, 2024 at 5:20 PM Alexander Korotkov wrote:
> On Tue, Nov 28, 2023 at 11:00 AM Pavel Borisov wrote:
> > > You're designing new APIs, days before the feature freeze.
> > On Wed, 5 Apr 2023 at 06:54, Michael Paquier wrote:
> > >
> > > On T
On Wed, Mar 20, 2024 at 7:19 PM Alexander Korotkov wrote:
> On Mon, Mar 11, 2024 at 3:44 PM Maxim Orlov wrote:
> > On Tue, 6 Feb 2024 at 09:22, Michael Paquier wrote:
> >> The problem may be actually trickier than that, no? Could there be
> >> other f
committed soon.
Pushed.
Thanks to Maxim and Pavel.
--
Regards,
Alexander Korotkov
e this patch, mostly comments and the commit message.
--
Regards,
Alexander Korotkov
v3-0001-Add-Index-level-REINDEX-with-multiple-jobs.patch
Description: Binary data
1 day (8640ms)
> CALL pg_wait_lsn('0/34FB5A1',100);
> WARNING: Timeout for pg_wait_lsn() restricted to 1 day
I don't think we need to mention individuals, who made proposals, in the
source code comments. Otherwise, our source code would be a crazy mess of
names. Also, if this is the restriction, it has to be an error. And it
should be a proper full ereport().
--
Regards,
Alexander Korotkov
Hi, Pavel!
On Tue, Nov 28, 2023 at 11:00 AM Pavel Borisov wrote:
> > You're designing new APIs, days before the feature freeze.
> On Wed, 5 Apr 2023 at 06:54, Michael Paquier wrote:
> >
> > On Tue, Apr 04, 2023 at 01:25:46AM +0300, Alexander Korotkov wrote:
> > > P
nce is running?
I think this would be a good point to start studying.
https://www.interdb.jp/
The information there should be more than enough to forget this idea forever :)
--
Regards,
Alexander Korotkov
ped or didn't do any modifications
since the last checkpoint.
--
Regards,
Alexander Korotkov
is about having a binary copy of the database on the
filesystem level.
https://www.postgresql.org/docs/current/backup-file.html
--
Regards,
Alexander Korotkov
On Tue, Mar 19, 2024 at 1:51 PM Amit Kapila wrote:
> On Mon, Mar 18, 2024 at 3:24 PM Alexander Korotkov
> wrote:
> >
> > On Mon, Mar 18, 2024 at 5:17 AM Amit Kapila wrote:
> > > > 1. First, check that it was called with non-atomic context (that is,
> > >
s a chain of domain dependencies, it will recurse
> until finding the base type.
>
>
>
> also, I think this way, we only do one syscache lookup.
Looks good to me. But should it be named pg_basetypeof()?
--
Regards,
Alexander Korotkov
On Mon, Mar 18, 2024 at 5:17 AM Amit Kapila wrote:
> On Sun, Mar 17, 2024 at 7:40 PM Alexander Korotkov
wrote:
> > On Sat, Mar 16, 2024 at 5:05 PM Bharath Rupireddy
> > wrote:
> > > On Sat, Mar 16, 2024 at 4:26 PM Amit Kapila
wrote:
> > > > In general
Bharath, what do you think about this approach? Is this a way to go?
--
Regards,
Alexander Korotkov
On Fri, Mar 15, 2024 at 10:32 PM Kartyshov Ivan
wrote:
>
> On 2024-03-15 22:59, Kartyshov Ivan wrote:
> > On 2024-03-11 13:44, Alexander Korotkov wrote:
> >> I picked the second option and left only the AFTER clause for the
> >> BEGIN statement. I think this shou
On Fri, Mar 15, 2024 at 4:20 PM Alexander Korotkov
wrote:
> On Mon, Mar 11, 2024 at 12:44 PM Alexander Korotkov
> wrote:
> > I've decided to put my hands on this patch.
> >
> > On Thu, Mar 7, 2024 at 2:25 PM Amit Kapila
> wrote:
> > > +1 for the second one
On Mon, Mar 11, 2024 at 12:44 PM Alexander Korotkov
wrote:
> I've decided to put my hands on this patch.
>
> On Thu, Mar 7, 2024 at 2:25 PM Amit Kapila wrote:
> > +1 for the second one not only because it avoids new words in grammar
> > but also sounds to convey the mea
inks.
1.
https://tiswww.case.edu/php/chet/readline/readline.html#index-rl_005fbasic_005fword_005fbreak_005fcharacters
--
Regards,
Alexander Korotkov
On Thu, Mar 14, 2024 at 12:11 PM Andrei Lepikhov
wrote:
>
> On 14/3/2024 16:31, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > > On 13/3/2024 18:05, Alexander Korotkov wrote:
> &g
On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
wrote:
> On 13/3/2024 18:05, Alexander Korotkov wrote:
> > On Wed, Mar 13, 2024 at 7:52 AM Andrei Lepikhov
> > Given all of the above, I think moving transformation to the
> > canonicalize_qual() would be the right way to
On Mon, Mar 11, 2024 at 11:48 AM Alexander Korotkov
wrote:
>
> On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
> wrote:
> > On 11.03.2024 03:39, Alexander Korotkov wrote:
> > > Now that we distinguish stats for checkpoints and
> > > restartpoints, we need t
On Wed, Mar 13, 2024 at 7:52 AM Andrei Lepikhov
wrote:
> On 12/3/2024 22:20, Alexander Korotkov wrote:
> > On Mon, Mar 11, 2024 at 2:43 PM Andrei Lepikhov
> >> I think you are right. It is probably a better place than any other to
> >> remove duplicates in an array.
On Wed, Mar 13, 2024 at 7:56 AM Andrey M. Borodin wrote:
> > On 13 Mar 2024, at 05:23, Alexander Korotkov wrote:
> >
> > On Tue, Mar 12, 2024 at 10:28 AM Andrey M. Borodin
> > wrote:
> >>> On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
> &g
On Tue, Mar 12, 2024 at 10:28 AM Andrey M. Borodin wrote:
> > On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
> >
> > I think if checking psql stderr is problematic, checking just logs is
> > fine. Could we wait for the relevant log messages one by one with
> &
On Mon, Mar 11, 2024 at 2:43 PM Andrei Lepikhov
wrote:
> On 11/3/2024 18:31, Alexander Korotkov wrote:
> >> I'm not convinced about this limit. The initial reason was to combine
> >> long lists of ORs into the array because such a transformation made at
> >> an ea
On Sun, Jan 14, 2024 at 4:35 AM Alexander Korotkov wrote:
> On Sat, Jan 13, 2024 at 7:33 PM Dmitry Koval wrote:
> > Thank you, there is one small point left (in the comment): can you
> > replace "guarantteed to be to be newer" to "guaranteed to be newer"
Hi Andrei,
Thank you for your response.
On Mon, Mar 11, 2024 at 7:13 AM Andrei Lepikhov
wrote:
> On 7/3/2024 21:51, Alexander Korotkov wrote:
> > Hi!
> >
> > On Tue, Mar 5, 2024 at 9:59 AM Andrei Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> >
On Mon, Mar 11, 2024 at 12:53 PM Andrey M. Borodin wrote:
> > On 7 Mar 2024, at 00:55, Alexander Korotkov wrote:
> >
> > On Wed, Mar 6, 2024 at 10:22 AM Andrey M. Borodin
> > wrote:
> >>> On 25 Feb 2024, at 21:50, Alexander Korotkov wrote:
> >>&g
k if LSN is replayed after adding
to the shared memory array. This should save from the race
conditions.
5) I've renamed too generic names for functions and files.
--
Regards,
Alexander Korotkov
v8-0001-Implement-AFTER-clause-for-BEGIN-command.patch
Description: Binary data
On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
wrote:
> On 11.03.2024 03:39, Alexander Korotkov wrote:
> > Now that we distinguish stats for checkpoints and
> > restartpoints, we need to update the docs. Please, check the patch
> > atta
On Thu, Mar 7, 2024 at 11:07 AM Alexander Korotkov wrote:
> On Thu, Mar 7, 2024 at 9:53 AM Egor Chindyaskin wrote:
> >
> > > 6 march 2024 г., at 19:17, Alexander Korotkov
> > > wrote:
> > >
> > > The revised set of remaining patches is a
lease, check the patch
attached.
--
Regards,
Alexander Korotkov
rename_pg_stat_get_checkpointer_fields.patch
Description: Binary data
On Thu, Mar 7, 2024 at 1:49 AM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > Sorry for tediousness, but isn't pre-order a variation of depth-first order
> > [1]?
>
> To me, depth-first implies visiting children before parents.
> Do I have the terminology wro
t might make query execution
performance somewhat worse, and also makes selectivity estimation worse. I
suggest Andrei and/or Alena should implement making array values unique.
--
Regards,
Alexander Korotkov
v20-0002-Teach-generate_bitmap_or_paths-to-build-BitmapOr.patch
Description: Binar
Hi, Egor!
On Thu, Mar 7, 2024 at 9:53 AM Egor Chindyaskin wrote:
>
> > 6 march 2024 г., at 19:17, Alexander Korotkov wrote:
> >
> > The revised set of remaining patches is attached.
> >
> > 0001 Turn tail recursion into iteration in CommitTransactionC
On Thu, Mar 7, 2024 at 12:52 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > The revised set of remaining patches is attached.
> > ...
> > 0003 Avoid recursion in MemoryContext functions
> > I've renamed MemoryContextTraverse() => MemoryContextTraverseNext(),
&
On Wed, Mar 6, 2024 at 10:22 AM Andrey M. Borodin wrote:
> > On 25 Feb 2024, at 21:50, Alexander Korotkov wrote:
> >
> > Thank you for the patches. I've pushed the 0001 patch to avoid
> > further failures on buildfarm. Let 0004 wait till injections points
>
On Wed, Feb 14, 2024 at 2:00 PM Alexander Korotkov wrote:
> On Fri, Jan 12, 2024 at 11:00 PM Robert Haas wrote:
> > On Fri, Jan 12, 2024 at 10:12 AM Heikki Linnakangas wrote:
> > > Here's one goto-free attempt. It adds a local loop to where the
> > > recursion was,
On Mon, Nov 27, 2023 at 10:18 PM Mark Dilger
wrote:
>
> > On Nov 25, 2023, at 9:47 AM, Alexander Korotkov
> > wrote:
> >
> >> Should the patch at least document which parts of the EState are expected
> >> to be in which states, and wh
Hi, Matthias!
On Fri, Nov 24, 2023 at 1:07 AM Matthias van de Meent
wrote:
> On Thu, 23 Nov 2023 at 13:43, Alexander Korotkov wrote:
> >
> > Hello PostgreSQL Hackers,
> >
> > I am pleased to submit a series of patches related to the Table Access
> > Method
anges.
>
I'm going to review and revise the patch.
One question I have yet.
>/*
> * Transformation only works with both side type is not
> * { array | composite | domain | record }.
Why do we limit transformation for these types? Also, it doesn't seem the
current code restricts anything except composite/record.
--
Regards,
Alexander Korotkov
ded as part of
upgrades of existing extensions. There is probably no consensus yet
on what to do with existing extensions like jsonb_plperl and
jsonb_plpython, but we clearly shouldn't spread such cases.
--
Regards,
Alexander Korotkov
umeInput failed: server closed the connection
> unexpectedly" as in [1]).
Thank you for the patches. I've pushed the 0001 patch to avoid
further failures on buildfarm. Let 0004 wait till injections points
by Mechael are committed.
--
Regards,
Alexander Korotkov
Hi, Noah!
On Sat, Feb 24, 2024 at 7:12 AM Noah Misch wrote:
> On Sat, Feb 24, 2024 at 12:36:59AM +0200, Alexander Korotkov wrote:
> > On Thu, Feb 22, 2024 at 10:51 AM Andrei Lepikhov
> > wrote:
> > > On 21/2/2024 14:26, Richard Guo wrote:
> > > > I
edits from me.
--
Regards,
Alexander Korotkov
what we want.
Your patch reduces the number of rows to 1000 tuples. I found it
possible to further reduce it to 100 tuples. That also allowed me to
save the plan in the test case introduced by e1b7fde418.
Please check if you're OK with the patch attached.
--
Regards,
Alexander Korotkov
0
e second one is not needed?
>
> Yeah, that's funny. It looks like such a double protection emerged
> because Alvaro protected the function (in b0f7dd915), which was waiting for
> adding check_stack_depth() in the other thread (resulted in d57b7cc33).
>
> Thank you for spending ti
ho didn't manage to use mmap() properly. We're
not idiots, we develop DBMS of high concurrency! :-)
--
Regards,
Alexander Korotkov
On Sun, Feb 18, 2024 at 5:04 PM Alexander Korotkov wrote:
> On Sun, Feb 18, 2024 at 3:00 PM Alexander Lakhin wrote:
> > 09.01.2024 01:09, Alexander Korotkov wrote:
> >
> > Fixed in 30b4955a46.
> >
> >
> > Please look at the following query which
On Sun, Feb 18, 2024 at 3:00 PM Alexander Lakhin wrote:
> 09.01.2024 01:09, Alexander Korotkov wrote:
>
> Fixed in 30b4955a46.
>
>
> Please look at the following query which fails with an error since
> d3d55ce57:
>
> create table t (i int primary key);
>
> select
unctions, which seem to be not
used in critical states where abortion can lead to a panic. I've
extracted them from [2] into an attached 0002 patch. I'd like to push
it if there is no objection.
Links.
1.
https://www.postgresql.org/message-id/6b48c746-9704-46dc-b9be-01fe4137c824%40iki.fi
2.
https
Links.
1.
https://www.postgresql.org/message-id/20221206011050.s6hapukjqha35hud%40alap3.anarazel.de
--
Regards,
Alexander Korotkov
0001-Introduce-transaction_timeout-v26.patch
Description: Binary data
e and pretty simple optimization. I've
merged the changes by Alena, and slightly revised the code changes in
convert_ANY_sublink_to_join(). I'm going to push this if there are no
objections.
--
Regards,
Alexander Korotkov
0001-Pull-up-ANY-SUBLINK-with-the-necessary-lateral-su-v6.patch
Descrip
ds for me when set
"use_remote_estimate = true" for the server;
> But the worst thing is that replacing AND with OR causes breaking session and
> server restart:
I haven't managed to reproduce this yet. Could you give more details:
machine, OS, compile options, backtrace?
f, verbose) SELECT *
> FROM aircrafts a
> WHERE a.aircraft_code = '320' OR EXISTS (
> SELECT * FROM seats s WHERE s.aircraft_code = a.aircraft_code
> );
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> The connection to the server was lost. Attempting reset: Failed.
Thank you, Pavel. I'm looking into this.
--
Regards,
Alexander Korotkov
> gcc 13.2.1, but *not* when using RHEL8's gcc 8.5.0.
>
> It's visible here with gcc >= 10. That's enough versions that I think we
> should care. Interestingly enough, it seems to have recently have gotten
> fixed in gcc master (14 to be).
I managed to reproduce this warning locally. Fixed.
--
Regards,
Alexander Korotkov
Hi, Alexander!
On Mon, Feb 5, 2024 at 7:00 PM Alexander Lakhin wrote:
> 05.02.2024 02:51, Alexander Korotkov wrote:
>
> > Usage of heap_inplace_update() seems appropriate for me here. It
> > avoids trouble with both TOAST and row-level locks. Alexander, could
> > you p
On Tue, Jan 23, 2024 at 11:52 PM Alexander Korotkov
wrote:
> On Tue, Jan 23, 2024 at 8:00 PM Alexander Lakhin wrote:
> > Please look at the following query, which triggers an assertion failure on
> > updating the field dathasloginevt for an entry in pg_database:
> >
"occupy"
> Removed on of the two "amounts"
> Changed "unacceptable to the input function" to just "converting" as that is
> what the average reader is more likely to be thinking.
> The rest was good.
Thanks to everybody in the thread.
Pushed.
--
Regards,
Alexander Korotkov
-bin/show_log.pl?nm=piculet=2024-01-24%2014%3A05%3A14
Thank you for catching this. Fixed.
--
Regards,
Alexander Korotkov
essage-id/1284094.1695479962%40sss.pgh.pa.us
Thank you for reporting. I'm looking into this...
I wonder if there is a way to avoid toast update given that we don't
touch the toasted field here.
--
Regards,
Alexander Korotkov
On Wed, Jan 17, 2024 at 11:08 PM Alexander Korotkov
wrote:
> On Wed, Jan 17, 2024 at 7:47 AM Michael Paquier wrote:
> > rorqual has failed today with a very interesting failure:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rorqual=2024-01-17%2005%3A06%3A31
> >
I've done this in the revised patchset.
I'm going to push this if there are no objections.
--
Regards,
Alexander Korotkov
0002-Explore-alternative-orderings-of-group-by-p-20240119.patch
Description: Binary data
0001-Generalize-common-code-of-adding-sort-befor-20240119.patch
Description: Binary data
GNORE'.
> How about something like this?
>
>If ON_ERROR is specified and the value is not STOP, skip rows with
> soft errors
I think when we have more options, then we wouldn't just skip rows
with soft errors but rather save them. So, I left this comment as is
for now.
--
Regards,
Alexander Korotkov
r_action or on_error is better, but either way
> "error_action error" and "on_error error" seems a bit odd to me.
> I feel "stop" is better for both cases as Tom suggested.
OK. What about this?
on_error {stop|ignore|other_future_option}
where other_future_option might be compound like "file 'copy.log'" or
"table 'copy_log'".
--
Regards,
Alexander Korotkov
aky it seems.
+1
Thank you, Daniel. I think you described everything absolutely
correctly. As I wrote upthread, it doesn't seem much could be done
with this, at least within a regression test. So, I just removed this
query from the test.
--
Regards,
Alexander Korotkov
, must be from a prev epoch. */
> Assert(epoch > 0);
> epoch--;
> }
>
> This would mean that we've found a way to get a negative epoch, which
> should not be possible.
>
> Alexander, you have added this code in 5a1dfde8334b when switching the
> 2PC file names to use FullTransactionIds. Could you check please?
Thank you for reporting! I'm going to look at this in the next couple of days.
--
Regards,
Alexander Korotkov
t SAVE_ERROR_TO is followed by action. Probably, we can
replace SAVE_ERROR_TO with another name which could be naturally
followed by action, but I don't have something appropriate in mind.
However, I'm not native english speaker and certainly could miss
something.
--
Regards,
Alexander Korotkov
uld be 'was' here?
Sure, the fix is pushed.
--
Regards,
Alexander Korotkov
e should add a column to pg_stat_progress_copy that
> counts soft errors. I'll suggest this in another thread.
Please do!
--
Regards,
Alexander Korotkov
0001-Add-new-COPY-option-SAVE_ERROR_TO-v6.patch
Description: Binary data
Hi!
Thank you for your review. The revised patchset is attached.
On Tue, Jan 16, 2024 at 4:48 AM Richard Guo wrote:
> On Mon, Jan 15, 2024 at 3:56 PM Alexander Korotkov
> wrote:
>>
>> On Mon, Jan 15, 2024 at 8:42 AM Richard Guo wrote:
>> > On Mon, Jan 15, 2024 at
On Mon, Jan 15, 2024 at 8:44 AM Masahiko Sawada wrote:
>
> On Mon, Jan 15, 2024 at 8:21 AM Alexander Korotkov
> wrote:
> >
> > On Sun, Jan 14, 2024 at 10:35 PM Masahiko Sawada
> > wrote:
> > > Thank you for updating the patch. Here are two comments:
On Mon, Jan 15, 2024 at 8:42 AM Richard Guo wrote:
> On Mon, Jan 15, 2024 at 8:20 AM Alexander Korotkov
> wrote:
>>
>> Thank you for providing the test case relevant for this code change.
>> The revised patch incorporating this change is attached. Now the
>> p
But I doubt I would
find a solution other than removing the flaky parts of the test.
--
Regards,
Alexander Korotkov
On Sun, Jan 14, 2024 at 2:14 PM Andrei Lepikhov
wrote:
> On 13/1/2024 22:00, Alexander Korotkov wrote:
> > On Sat, Jan 13, 2024 at 11:09 AM Andrei Lepikhov
> > wrote:
> >> On 11/1/2024 18:30, Alexander Korotkov wrote:
> >>> On Tue, Jan 9, 2024 at 1:14 PM Pave
icing this. I think NOTICE is more appropriate here.
There is nothing to "worry" about: the user asked to ignore the errors
and we did. And yes, it doesn't make sense to use the last line as
the context. Fixed.
> ---
> +-- test missing data: should fail
> +COPY check_ig
ixed. Thank you for catching this.
--
Regards,
Alexander Korotkov
0001-Fix-false-reports-in-pg_visibility-v5.patch
Description: Binary data
; add redundant test, save_error_to with COPY TO test.
I've incorporated these changes. Also, I've changed
CopyFormatOptions.save_error_to to enum and made some edits in
comments and the commit message. I'm going to push this if there are
no objections.
--
Regards,
Alexander Korotkov
0001-Add-new-COPY-option-SAVE_ERROR_TO-v3.patch
Description: Binary data
On Sat, Jan 13, 2024 at 11:09 AM Andrei Lepikhov
wrote:
> On 11/1/2024 18:30, Alexander Korotkov wrote:
> > On Tue, Jan 9, 2024 at 1:14 PM Pavel Borisov wrote:
> >>> Hmm, I don't see this old code in these patches. Resend 0002-* because
> >>> of trailing spaces.
new version of the whole patchset
> should be sent even if most patches are unchanged.
Please, find the revised patchset with some refactoring and comments
improvement from me. I'll continue looking into this.
--
Regards,
Alexander Korotkov
0001-Generalize-common-code-of-addin
and sacrifices accuracy. But this
is the only way I can imagine, we can fix the problem in a general
way.
--
Regards,
Alexander Korotkov
0001-Fix-false-reports-in-pg_visibility-v5.patch
Description: Binary data
On Tue, Jan 9, 2024 at 8:08 AM Alexander Korotkov wrote:
> On Tue, Jan 9, 2024 at 6:00 AM Alexander Lakhin wrote:
> > 09.01.2024 01:09, Alexander Korotkov wrote:
> > > Fixed in 30b4955a46.
> >
> > Thank you for fixing that!
> >
> > I've found another
On Tue, Jan 9, 2024 at 6:00 AM Alexander Lakhin wrote:
> 09.01.2024 01:09, Alexander Korotkov wrote:
> > Fixed in 30b4955a46.
>
> Thank you for fixing that!
>
> I've found another anomaly coined with d3d55ce57. This query:
> CREATE TABLE t(a int PRIMARY KEY, b int);
>
On Mon, Jan 8, 2024 at 10:20 PM Alexander Korotkov wrote:
> On Mon, Jan 8, 2024 at 10:00 PM Alexander Lakhin wrote:
> > Please look at the following query which produces an incorrect result since
> > d3d55ce57:
> > CREATE TABLE t(a int PRIMARY KEY, b int);
> > INSERT I
M t t2 WHERE t2.a = t.b AND t2.b >
> 0);
>
> a | b
> ---+---
> 1 | 1
> (1 row)
>
> I think that the expected result is:
> a | b
> ---+---
> 1 | 1
> 2 | 1
> (2 rows)
Thank you for your report. I'm looking at this now.
--
Regards,
Alexander Korotkov
o match them to ORDER BY pathkeys too.
--
Regards,
Alexander Korotkov
On Wed, Dec 27, 2023 at 1:18 PM Pavel Borisov wrote:
> Thank you for revised comments! I think they are good enough.
Pushed, thank you!
--
Regards,
Alexander Korotkov
On Wed, Dec 27, 2023 at 2:04 PM Richard Guo wrote:
> On Wed, Dec 27, 2023 at 8:00 PM Alexander Korotkov
> wrote:
>>
>> On Wed, Dec 27, 2023 at 1:54 PM Andreas Seltenreich
>> wrote:
>> > SQLsmith found a failing Assertion in joininfo.c on master. I can
t join
> (t1 as t1a inner join t1 as t1b on t1a.a = t1b.a)
> on t1a.a is not null and exists (select);
>
> -- TRAP: failed Assert("list_member_ptr(rel->joininfo, restrictinfo)"), File:
> "joininfo.c", Line: 144, PID: 777839
Thank you for pointi
On Wed, Dec 27, 2023 at 5:23 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > 2) An accurate estimate of the sorting cost is quite a difficult task.
>
> Indeed.
>
> > What if we make a simple rule of thumb that sorting integers and
> > floats is cheaper tha
On Tue, Dec 26, 2023 at 1:37 PM Andrei Lepikhov
wrote:
> On 21/12/2023 17:53, Alexander Korotkov wrote:
> > On Sun, Oct 1, 2023 at 11:45 AM Andrei Lepikhov
> > wrote:
> >> New version of the patch. Fixed minor inconsistencies and rebased onto
> >> current master.
On Sun, Dec 24, 2023 at 2:02 PM Alexander Korotkov wrote:
> The most noticeable thing for me is that self-join removal doesn't work with
> partitioned tables. I think this is the direction for future work on this
> subject. In non-partitioned cases, patchset gives a small memory
to the scan direction).
> Maybe, in this case, it would be more clear like: "...(for backwards scan it
> will be the first item on a page)"
>
> Otherwise the patch 0002 looks like a good fix for the bug to be pushed.
Thank you for your review. I've revised comments to meet your su
On Fri, Dec 22, 2023 at 7:24 PM Andrei Lepikhov
wrote:
> On 22/12/2023 11:48, Alexander Korotkov wrote:
> > > Because we must trust all predictions made by the planner, we just
> > > choose the most trustworthy path. According to the planner logic, it is
> > > a p
On Mon, Dec 25, 2023 at 2:56 AM Ashutosh Bapat
wrote:
> On Sun, Dec 24, 2023 at 5:32 PM Alexander Korotkov
> wrote:
> >
> >
> > Thank you Ashutosh for your work on this matter. With a large number of
> > partitions, it definitely makes sense to reduce both
On Sat, Dec 23, 2023 at 12:04 AM Alexander Korotkov
wrote:
> 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
>> > (&qu
On Tue, Dec 12, 2023 at 3:22 PM Alexander Korotkov wrote:
>
> On Mon, Dec 11, 2023 at 6:16 PM Peter Geoghegan wrote:
> > Will you be in Prague this week? If not this might have to wait.
>
> Sorry, I wouldn't be in Prague this week. Due to my current
> immigration status
101 - 200 of 1179 matches
Mail list logo
