I ran into a situation that echoed this original one by Kato in the
start of this thread:
https://www.postgresql.org/message-id/OSAPR01MB374809E8DE169C8BF2B82CBD9F6B0%40OSAPR01MB3748.jpnprd01.prod.outlook.com
More below.
Tom Lane writes:
>
> I tried running the original test case under HEAD. I
On Fri, Sep 4, 2020 at 12:05 AM Tom Lane wrote:
>
> Amit Langote writes:
> >> Fwiw, I am fine with applying the memory-leak fix in all branches down
> >> to v12 if we are satisfied with the implementation.
>
> > I have revised the above patch slightly to introduce a variable for
> > the condition
Amit Langote writes:
>> Fwiw, I am fine with applying the memory-leak fix in all branches down
>> to v12 if we are satisfied with the implementation.
> I have revised the above patch slightly to introduce a variable for
> the condition whether to use a temporary memory context.
This CF entry has
On Thu, Aug 20, 2020 at 10:50 AM Amit Langote wrote:
On Thu, Aug 20, 2020 at 3:06 AM Alvaro Herrera
wrote:
> > On 2020-Aug-19, Amit Langote wrote:
> > > On Thu, Aug 6, 2020 at 4:25 PM kato-...@fujitsu.com
> > > wrote:
> > > > On Wednesday, August 5, 2020 9:43 AM I wrote:
> > > > > I'll report t
Hi,
On Thu, Aug 20, 2020 at 3:06 AM Alvaro Herrera wrote:
> On 2020-Aug-19, Amit Langote wrote:
> > On Thu, Aug 6, 2020 at 4:25 PM kato-...@fujitsu.com
> > wrote:
> > > On Wednesday, August 5, 2020 9:43 AM I wrote:
> > > > I'll report the result before the end of August .
> > >
> > > I test v2-0
On 2020-Aug-19, Amit Langote wrote:
Hello
> On Thu, Aug 6, 2020 at 4:25 PM kato-...@fujitsu.com
> wrote:
> > On Wednesday, August 5, 2020 9:43 AM I wrote:
> > > I'll report the result before the end of August .
> >
> > I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.
>
> I
Hi Alvaro,
On Thu, Aug 6, 2020 at 4:25 PM kato-...@fujitsu.com
wrote:
> On Wednesday, August 5, 2020 9:43 AM I wrote:
> > I'll report the result before the end of August .
>
> I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.
Is this patch meant for HEAD or back-patching? I
On Wednesday, August 5, 2020 9:43 AM I wrote:
> I'll report the result before the end of August .
I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.
Firstly, I execute ALTER TABLE ADD CONSTRAINT FOREIGN KEY on the table which
has 8k tables.
This query execution completes in a
On Tuesday, July 14, 2020 11:29 PM, Daniel Fustafsson wrote:
>Are you able to test Alvaros latest patch to see if that solves the originally
>reported problem, so that we can reach >closure on this item during the
>commitfest?
Sorry for the too late replay. I missed this mail.
And, thanks for w
> On 24 Mar 2020, at 16:26, Alvaro Herrera wrote:
> It
> would be great if Kato Sho can try the original test case with my latest
> patch (the one in https://postgr.es/m/20191113214544.GA16060@alvherre.pgsql )
> and let us know if it improves things.
Hi!,
Are you able to test Alvaros latest pat
On 2020-Mar-24, David Steele wrote:
> This patch still applies but there seems to be some disagreement on
> how to proceed.
Actually, I don't think there's any disagreement regarding the patch I
last posted. (There was disagreement on the previous patches, which
were very different). Tom sugges
On 11/13/19 4:45 PM, Alvaro Herrera wrote:
>
But it is not totally
unreasonable to have lots of partitions, and as we improve the system,
more and more people will want to.
+1
This patch still applies but there seems to be some disagreement on how
to proceed.
Any thoughts?
Regards,
--
-Dav
On Wed, Nov 13, 2019 at 4:46 PM Alvaro Herrera wrote:
> But it is not totally
> unreasonable to have lots of partitions, and as we improve the system,
> more and more people will want to.
Yep.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 2019-Nov-13, Alvaro Herrera wrote:
> On 2019-Nov-13, Tom Lane wrote:
>
> > (BTW, a different question one could ask is exactly why
> > RelationBuildPartitionDesc is so profligate of leaked memory.)
>
> The original partitioning code (f0e44751d717) decided that it didn't
> want to bother with
On 2019-Nov-13, Tom Lane wrote:
> (BTW, a different question one could ask is exactly why
> RelationBuildPartitionDesc is so profligate of leaked memory.)
The original partitioning code (f0e44751d717) decided that it didn't
want to bother with adding a "free" routine for PartitionBoundInfo
struct
Alvaro Herrera writes:
> On 2019-Oct-25, Tomas Vondra wrote:
>> The attached patch trivially fixes that by adding a memory context
>> tracking all the temporary data, and then just deletes it as a whole at
>> the end of the function. This significantly reduces the memory usage for
>> me, not sure
On 2019-Oct-25, Tomas Vondra wrote:
> The attached patch trivially fixes that by adding a memory context
> tracking all the temporary data, and then just deletes it as a whole at
> the end of the function. This significantly reduces the memory usage for
> me, not sure it's 100% correct.
FWIW we a
Hello,
On Fri, Oct 25, 2019 at 7:18 AM Tomas Vondra
wrote:
> On Thu, Oct 24, 2019 at 03:48:57PM -0300, Alvaro Herrera wrote:
> >On 2019-Oct-23, kato-...@fujitsu.com wrote:
> >
> >> Hello
> >>
> >> To benchmark with tpcb model, I tried to create a foreign key in the
> >> partitioned history table
On Thu, 31 Oct 2019 at 17:56, Tom Lane wrote:
>
> David Rowley writes:
> > In Ottawa this year, Andres and I briefly talked about the possibility
> > of making a series of changes to how equalfuncs.c works. The idea was
> > to make it easy by using some pre-processor magic to allow us to
> > crea
David Rowley writes:
> In Ottawa this year, Andres and I briefly talked about the possibility
> of making a series of changes to how equalfuncs.c works. The idea was
> to make it easy by using some pre-processor magic to allow us to
> create another version of equalfuncs which would let us have an
Hi,
On 2019-10-31 11:19:05 +1300, David Rowley wrote:
> In Ottawa this year, Andres and I briefly talked about the possibility
> of making a series of changes to how equalfuncs.c works. The idea was
> to make it easy by using some pre-processor magic to allow us to
> create another version of equa
On Thu, 31 Oct 2019 at 07:30, Tomas Vondra wrote:
>
> On Thu, Oct 24, 2019 at 04:28:38PM -0700, Andres Freund wrote:
> >Hi,
> >
> >On 2019-10-23 05:59:01 +, kato-...@fujitsu.com wrote:
> >> To benchmark with tpcb model, I tried to create a foreign key in the
> >> partitioned history table, bu
On Thu, Oct 24, 2019 at 04:28:38PM -0700, Andres Freund wrote:
Hi,
On 2019-10-23 05:59:01 +, kato-...@fujitsu.com wrote:
To benchmark with tpcb model, I tried to create a foreign key in the
partitioned history table, but backend process killed by OOM.
the number of partitions is 8192. I tr
Hi,
On 2019-10-23 05:59:01 +, kato-...@fujitsu.com wrote:
> To benchmark with tpcb model, I tried to create a foreign key in the
> partitioned history table, but backend process killed by OOM.
> the number of partitions is 8192. I tried in master(commit: ad4b7aeb84).
Obviously this should be
On Fri, Oct 25, 2019 at 12:17:58AM +0200, Tomas Vondra wrote:
...
FWIW, even with this fix it still takes an awful lot to create the
foreign key, because the CPU is stuck doing this
60.78%60.78% postgres postgres[.] bms_equal
32.58%32.58% postgres postgres
On Thu, Oct 24, 2019 at 03:48:57PM -0300, Alvaro Herrera wrote:
On 2019-Oct-23, kato-...@fujitsu.com wrote:
Hello
To benchmark with tpcb model, I tried to create a foreign key in the
partitioned history table, but backend process killed by OOM.
the number of partitions is 8192. I tried in mas
On 2019-Oct-23, kato-...@fujitsu.com wrote:
> Hello
>
> To benchmark with tpcb model, I tried to create a foreign key in the
> partitioned history table, but backend process killed by OOM.
> the number of partitions is 8192. I tried in master(commit: ad4b7aeb84).
>
> I did the same thing in ano
Hello
To benchmark with tpcb model, I tried to create a foreign key in the
partitioned history table, but backend process killed by OOM.
the number of partitions is 8192. I tried in master(commit: ad4b7aeb84).
I did the same thing in another server which has 200GB memory, but creating
foreign k
28 matches
Mail list logo
