В письме от пятница, 27 сентября 2019 г. 17:24:49 MSK пользователь Michael
Paquier написал:
> The patch is in this state for two months now, so I have switched it
> to "returned with feedback".
So I've split this patch into even smaller parts, so it would be more easy to
review.
Do not use
On Thu, Aug 01, 2019 at 09:39:53PM +1200, Thomas Munro wrote:
> Looks like some good actionable feedback. I've moved this patch to
> September, and set it to "Waiting on Author".
The patch is in this state for two months now, so I have switched it
to "returned with feedback". The latest patch
On Sat, Jul 13, 2019 at 2:14 AM Nikolay Shaplov wrote:
> Here goes an updated version.
On Sat, Jul 20, 2019 at 8:21 PM Dent John wrote:
> [review]
On Sun, Jul 28, 2019 at 5:38 AM Tomas Vondra
wrote:
> [review]
Hi Nikolay,
Looks like some good actionable feedback. I've moved this patch to
Hi Nikolay,
thanks for sending a new version of the patch. I've done a basic review
today, so let me share some comments about the patch.
Firstly, there's an important question why should we actually do this.
At the beginning of this thread you mentioned memory usage - e.g. for
indexes the
Hi Nikolay,
Thanks for the revised patch. It applies now no problem, and seems to work fine.
For me, I still find the relopts area quite odd. I wonder if your patch doesn’t
go far enough?
For example, take log_autovacuum_min_duration. It’s described intRelOpts, which
implicitly defines its
В письме от четверг, 4 июля 2019 г. 19:44:42 MSK пользователь Dent John
написал:
> Hi Nikolay,
>
> I have had a crack at re-basing the current patch against 12b2, but I didn’t
> trivially succeed.
>
> It’s probably more my bodged fixing of the rejections than a fundamental
> problem. But I now
В письме от понедельник, 1 июля 2019 г. 23:52:13 MSK пользователь Thomas Munro
написал:
> > > This patch does not apply.
> >
> > Oh... Sorry... here goes new version
>
>
> Hi Nikolay,
>
> Could we please have a new rebase?
Sorry, a new reloptions have been introduced, and I need some time
On Thu, Jul 04, 2019 at 07:44:42PM +0100, Dent John wrote:
> I see that your patch removed that particular type, so I guess that
> feature in vacuum.c has been added in the meantime.
>
> Would you have a more recent patch?
I have switched the patch as waiting on author.
--
Michael
Hi Nikolay,
I have had a crack at re-basing the current patch against 12b2, but I didn’t
trivially succeed.
It’s probably more my bodged fixing of the rejections than a fundamental
problem. But I now get compile fails in — and seems like only — vacuum.c.
gcc -Wall -Wmissing-prototypes
It seems strange to have relation_reloptions which abstracts away the
need to know which function to call for each relkind, and separately
have a bunch of places that call the specific relkind. Why not just
call the specific function directly? It doesn't seem that we're gaining
any abstraction
On Mon, Apr 1, 2019 at 4:36 AM Nikolay Shaplov wrote:
> В письме от понедельник, 18 марта 2019 г. 3:03:04 MSK пользователь Iwata, Aya
> написал:
> > This patch does not apply.
> Oh... Sorry... here goes new version
Hi Nikolay,
Could we please have a new rebase?
Thanks,
--
Thomas Munro
В письме от среда, 20 марта 2019 г. 6:15:38 MSK пользователь Iwata, Aya
написал:
> You told us "big picture" about opclass around the beginning of this thread.
> In my understanding, the purpose of this refactoring is to make reloptions
> more flexible to add opclass. I understand this change
В письме от понедельник, 18 марта 2019 г. 17:00:24 MSK пользователь Kyotaro
HORIGUCHI написал:
> > So I change status to "Waiting for Author".
> That seems to be a good oppotunity. I have some comments.
>
> rel.h:
> -#define RelationGetToastTupleTarget(relation, defaulttarg) \
> -
В письме от понедельник, 18 марта 2019 г. 3:03:04 MSK пользователь Iwata, Aya
написал:
> Hi Nikolay,
Hi!
Sorry for long delay. Postgres is not my primary work, so sometimes it takes a
while to get to it.
> This patch does not apply.
Oh... Sorry... here goes new version
> Please refer to
Hi,
> hio.c:
>
> -saveFreeSpace = RelationGetTargetPageFreeSpace(relation,
> -
> HEAP_DEFAULT_FILLFACTOR);
> +if (IsToastRelation(relation))
> +saveFreeSpace = ToastGetTargetPageFreeSpace();
> +else
> +saveFreeSpace = HeapGetTargetPageFreeSpace(relation);
>
> This
Hello.
At Mon, 18 Mar 2019 03:03:04 +, "Iwata, Aya"
wrote in <71E660EB361DF14299875B198D4CE5423DF05777@g01jpexmbkw25>
> This patch does not apply. Please refer to http://commitfest.cputube.org/
> and update it.
> How about separating your patch by feature or units that can be phased
Hi Nikolay,
This patch does not apply. Please refer to http://commitfest.cputube.org/ and
update it.
How about separating your patch by feature or units that can be phased commit.
For example, adding assert macro at first, refactoring StdRdOptions by the
next, etc.
So I change status to
В письме от четверг, 17 января 2019 г. 20:33:06 MSK пользователь Alvaro
Herrera написал:
> You introduced new macros IsHeapRelation and IsViewRelation, but I don't
> want to introduce such API. Such things have been heavily contested and
> I don't to have one more thing to worry about for this
You introduced new macros IsHeapRelation and IsViewRelation, but I don't
want to introduce such API. Such things have been heavily contested and
I don't to have one more thing to worry about for this patch, so please
just put the relkind directly in the code.
On 2019-Jan-07, Nikolay Shaplov
В письме от понедельник, 7 января 2019 г. 13:56:48 MSK пользователь Alvaro
Herrera написал:
> > Asserts are cool thing. I found some unexpected stuff.
> >
> > parallel_workers option is claimed to be heap-only option.
> >
> > But in src/backend/optimizer/util/plancat.c in get_relation_info
> >
On 2019-Jan-07, Nikolay Shaplov wrote:
> Asserts are cool thing. I found some unexpected stuff.
>
> parallel_workers option is claimed to be heap-only option.
>
> But in src/backend/optimizer/util/plancat.c in get_relation_info
> RelationGetParallelWorkers is being called for both heap and
В письме от четверг, 3 января 2019 г. 17:15:08 MSK пользователь Alvaro Herrera
написал:
> > Can we think about backward compatibility aliases?
.
> > And keep them for as log as needed to avoid #if VERSION in thirdparty
> > code?
> Well, if you do this, at some point you need to tell the
В письме от четверг, 3 января 2019 г. 17:15:08 MSK пользователь Alvaro Herrera
написал:
> I would have liked to get a StaticAssert in the definition, but I don't
> think it's possible. A standard Assert() should be possible, though.
Asserts are cool thing. I found some unexpected stuff.
On 2019-Jan-03, Nikolay Shaplov wrote:
> Can we think about backward compatibility aliases?
>
> #define ViewHasCheckOption(relation) \
> ((relation)->rd_options && \
> ((ViewOptions *)
В письме от четверг, 3 января 2019 г. 16:10:20 MSK пользователь Alvaro Herrera
написал:
> On 2019-Jan-02, Nikolay Shaplov wrote:
> > This is internal API, right? If we change it everywhere, then it is
> > changed and nothing will be broken?
>
> No, it's exported for extensions to use. If we
On 2019-Jan-02, Nikolay Shaplov wrote:
> This is internal API, right? If we change it everywhere, then it is changed
> and nothing will be broken?
No, it's exported for extensions to use. If we change it unnecessarily,
extension authors will hate me (not you) for breaking the compile and
В письме от среда, 2 января 2019 г. 0:05:10 MSK пользователь Alvaro Herrera
написал:
> One thing I would like to revise here is to avoid unnecessary API change
> -- for example the RelationHasCascadedCheckOption macro does not really
> need to be renamed because it only applies to views, so
One thing I would like to revise here is to avoid unnecessary API change
-- for example the RelationHasCascadedCheckOption macro does not really
need to be renamed because it only applies to views, so there's no
possible conflict with other relation types. We can keep the original
name and add a
В письме от пятница, 30 ноября 2018 г. 23:57:21 MSK пользователь Dmitry Dolgov
написал:
> Looks like there are some problems with this patch on windows:
> src/backend/access/common/reloptions.c(1469): error C2059: syntax error :
> '}'
>
>
> On Mon, Nov 19, 2018 at 2:30 PM Nikolay Shaplov wrote:
>
> В письме от 2 октября 2018 13:46:13 пользователь Michael Paquier написал:
> > On Fri, Sep 14, 2018 at 09:30:25PM +0300, Nikolay Shaplov wrote:
> > > BTW this commit shows why do this patch is important: 857f9c36 adds new
> > > option
В письме от 2 октября 2018 13:46:13 пользователь Michael Paquier написал:
> On Fri, Sep 14, 2018 at 09:30:25PM +0300, Nikolay Shaplov wrote:
> > BTW this commit shows why do this patch is important: 857f9c36 adds new
> > option for b-tree indexes. But thanks to the StdRdOptions this option
> >
On Fri, Sep 14, 2018 at 09:30:25PM +0300, Nikolay Shaplov wrote:
> BTW this commit shows why do this patch is important: 857f9c36 adds new
> option
> for b-tree indexes. But thanks to the StdRdOptions this option will exist for
> no practical use in all heaps that has just any option set to
Hi!
I've rebased the patch against recent master.
I've imported changes from 857f9c36 commit.
BTW this commit shows why do this patch is important: 857f9c36 adds new option
for b-tree indexes. But thanks to the StdRdOptions this option will exist for
no practical use in all heaps that has just
Hi,
On 2018-03-02 20:22:21 +0300, Nikolay Shaplov wrote:
> Since I get a really big patch as a result, it was decided to commit it in
> parts.
I get that, but I strongly suggest not creating 10 loosely related
threads, but keeping it as a patch series in one thread. It's really
hard to follow
В письме от 1 марта 2018 16:15:32 пользователь Andres Freund написал:
> > This is part or my bigger patch
> > https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#21464
> > 19.veIEZdk4E4@x200m we've decided to commit by smaller parts.
>
> I've not read that thread. Is this
Hi,
On 2018-02-22 19:48:46 +0300, Nikolay Shaplov wrote:
> This is part or my bigger patch
> https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#2146419.veIEZdk4E4@x200m
> we've decided to
> commit by smaller parts.
I've not read that thread. Is this supposed to be a first
36 matches
Mail list logo
