On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson wrote:
> Hello all,
>
> Here is the updated patch which is rebased over v10 of Amit Langote's
> path towards faster pruning patch [1]. It modifies the PartScanKeyInfo
> struct to hold expressions which is then evaluated by the executor to
> fetch the c
On Fri, Nov 10, 2017 at 4:41 AM, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote:
>> Fixed in the 0003 patch.
>
> I have committed this patch set with the attached adjustments.
>
Thanks a lot for your support & a ton of thanks to all reviewer.
Regard
On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote
wrote:
> On 2017/11/06 14:32, David Rowley wrote:
>> On 6 November 2017 at 17:30, Amit Langote wrote:
>>> On 2017/11/03 13:32, David Rowley wrote:
On 31 October 2017 at 21:43, Amit Langote wrote:
[]
>
> Attached updated set of patches, includin
Hi Dilip,
v6 patch:
42 + /*
43 +* Estimate number of hashtable entries we can have within
maxbytes. This
44 +* estimates the hash cost as sizeof(PagetableEntry).
45 +*/
46 + nbuckets = maxbytes /
47 + (sizeof(PagetableEntry) + sizeof(Pointer) + sizeof(Pointer));
It too
On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote:
>> Although partition constraints become more simple, there isn't any
>> performance
>> gain with 0005 patch. Also I am little skeptic about logic in 0005 where
On Tue, Oct 31, 2017 at 9:54 AM, Robert Haas wrote:
> On Mon, Oct 30, 2017 at 5:52 PM, amul sul wrote:
>> Actually, int4[] is also inappropriate type as we have started using a 64bit
>> hash function. We need something int8[] which is not available, so that I
>> have us
On Tue, Oct 24, 2017 at 5:00 PM, Andres Freund wrote:
> On 2017-10-24 12:43:12 +0530, amul sul wrote:
>> I tried to get suggested SMHasher[1] test result for the hash_combine
>> for 32-bit and 64-bit version.
>>
>> SMHasher works on hash keys of the form {0}, {0,1}
On Fri, Oct 13, 2017 at 3:00 AM, Andres Freund wrote:
> On 2017-10-12 17:27:52 -0400, Robert Haas wrote:
>> On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote:
>> >> In other words, it's not utterly fixed in stone --- we invented
>> >> --load-via-partition-root primarily to cope with circumstan
On Thu, Oct 12, 2017 at 6:31 AM, Robert Haas wrote:
> On Tue, Oct 10, 2017 at 7:07 AM, amul sul wrote:
>> How about the attached patch(0003)?
>> Also, the dim variable is renamed to natts.
>
> I'm not sure I believe this comment:
>
> +/*
> +
On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat
wrote:
> On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote:
>
>>> +hash_part? true : key->parttypbyval[j],
>>> +key->parttyplen[j]);
>>> pa
On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote:
> On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat
> wrote:
>> On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote:
>>
>
> Thanks Ashutosh for your review, please find my comment inline.
>
>>
>>> 0002 few chan
On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat
wrote:
> On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote:
>
Thanks Ashutosh for your review, please find my comment inline.
>
>> 0002 few changes in partition-wise join code to support
>> hash-partitioned table as we
On Sat, Oct 7, 2017 at 5:22 PM, amul sul wrote:
> On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen
> wrote:
>> Hi Amul,
>>
>> Could you rebase on latest master ?
>>
>
> Sure will post that soon, but before that, I need to test hash partitioning
> with recent
On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen
wrote:
> Hi Amul,
>
> Could you rebase on latest master ?
>
Sure will post that soon, but before that, I need to test hash partitioning
with recent partition-wise join commit (f49842d1ee), thanks.
Regards,
Amul
--
Sent via pgsql-hackers mailing
On Wed, Sep 13, 2017 at 4:24 PM, amul sul wrote:
>
>
> On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila
> wrote:
>>
>> On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote:
>> > On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
>> > wrote:
>> >&g
On Thu, Sep 28, 2017 at 11:24 AM, Amit Langote
wrote:
> On 2017/09/27 22:41, Jesper Pedersen wrote:
>> On 09/27/2017 03:05 AM, amul sul wrote:
>>>>> Attached rebased patch, thanks.
>>>>>
>>>>>
>>>> While reading through the patch
Hi All,
Attaching POC patch that throws an error in the case of a concurrent update
to an already deleted tuple due to UPDATE of partition key[1].
In a normal update new tuple is linked to the old one via ctid forming
a chain of tuple versions but UPDATE of partition key[1] move tuple
from one pa
On Mon, Sep 18, 2017 at 8:55 PM, Jesper Pedersen wrote:
> On 09/15/2017 02:30 AM, amul sul wrote:
>
>> Attached rebased patch, thanks.
>>
>>
> While reading through the patch I thought it would be better to keep
> MODULUS and REMAINDER in caps, if CREATE TAB
On Wed, Sep 27, 2017 at 6:09 AM, Amit Langote wrote:
> On 2017/09/27 1:51, Robert Haas wrote:
> > On Tue, Sep 26, 2017 at 10:57 AM, Jesper Pedersen
> > wrote:
> >> One could advocate (*cough*) that the hash partition patch [1] should be
> >> merged first in order to find other instances of where
On Fri, Sep 22, 2017 at 11:47 AM, Andres Freund wrote:
> Hi,
>
> On 2017-09-20 18:26:50 +0530, amul sul wrote:
> > Patch 0007:
>
> Other than these concern, patch looks pretty reasonable to me.
>
> I'd appreciate if you could have a look at the new version as
On Wed, Sep 20, 2017 at 9:27 PM, Amit Khandekar
wrote:
> On 20 September 2017 at 00:06, Robert Haas wrote:
> > On Fri, Sep 15, 2017 at 7:25 AM, Amit Khandekar
> wrote:
> >> [ new patch ]
>
86 - (event == TRIGGER_EVENT_UPDATE &&
!trigdesc->trig_update_after_row))
87 + (e
Patch 0007:
1:
400 + /*
401 +* XXX: might be worthwhile to only handle oid sysattr, to
reduce
402 +* overhead - it's the most common key.
403 +*/
IMHO, let fix that as well. I tested this by fixing (see the attach patch)
but does
not found much gain on my local cento
On Fri, Sep 15, 2017 at 4:30 AM, Thom Brown wrote:
> On 14 September 2017 at 09:58, amul sul wrote:
> > On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen
> > wrote:
> >>
> >> Hi Amul,
> >>
> >> On 09/08/2017 08:40 AM, amul sul wrote:
> &
On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen wrote:
> Hi Amul,
>
> On 09/08/2017 08:40 AM, amul sul wrote:
>
>> Rebased 0002 against this commit & renamed to 0001, PFA.
>>
>>
> This patch needs a rebase.
>
>
Thanks for your note.
Attached is
On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila
wrote:
> On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote:
> > On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
> > wrote:
> >>
> >> On Wed, May 17, 2017 at 5:17 PM, Robert Haas
> >> wrote:
> >
On Mon, Sep 11, 2017 at 5:30 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat
> > wrote:
> > >> Rebased 0002 against this commit & renamed to 0001, PFA.
> > >
> > > Given that we have default partition support now, I am wondering
> > > whether ha
On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas wrote:
> On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote:
> > I've updated patch to use an extended hash function (Commit #
> > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning.
>
> Committed 0001 after notic
On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
wrote:
> On Wed, May 17, 2017 at 5:17 PM, Robert Haas
> wrote:
> > On Wed, May 17, 2017 at 6:29 AM, Amit Kapila
> wrote:
> >> I think we can do this even without using an additional infomask bit.
> >> As suggested by Greg up thread, we can set Inval
On Fri, Sep 1, 2017 at 8:01 AM, Robert Haas wrote:
> On Thu, Aug 31, 2017 at 8:40 AM, amul sul wrote:
> > Fixed in the attached version.
>
> I fixed these up a bit and committed them. Thanks.
>
> I think this takes care of adding not only the infrastructure but
> suppo
I've updated patch to use an extended hash function (Commit #
81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning.
Regards,
Amul
On Thu, Jul 27, 2017 at 5:11 PM, amul sul wrote:
> Attaching newer patches rebased against the latest master head. Thanks !
>
> Regards,
&
On Wed, Aug 30, 2017 at 9:05 PM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 10:43 AM, amul sul wrote:
> > Thanks for the suggestion, I have updated 0002-patch accordingly.
> > Using this I found some strange behaviours as follow:
> >
> > 1) standard and extended
On Tue, Aug 29, 2017 at 11:48 PM, Robert Haas wrote:
> On Tue, Aug 22, 2017 at 8:14 AM, amul sul wrote:
> > Attaching patch 0002 for the reviewer's testing.
>
> I think that this 0002 is not something we can think of committing
> because there's no guarantee that ha
On Tue, Aug 22, 2017 at 5:44 PM, amul sul wrote:
> On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas
> wrote:
>
>> On Fri, Aug 18, 2017 at 1:12 PM, amul sul wrote:
>> > I have a small query, what if I want a cache entry with extended hash
>> > function instead s
On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas wrote:
> On Fri, Aug 18, 2017 at 1:12 PM, amul sul wrote:
> > I have a small query, what if I want a cache entry with extended hash
> > function instead standard one, I might require that while adding
> > hash_array_extended f
On Fri, Aug 18, 2017 at 8:49 AM, Robert Haas wrote:
> On Wed, Aug 16, 2017 at 5:34 PM, Robert Haas
> wrote:
> > Attached is a quick sketch of how this could perhaps be done (ignoring
> > for the moment the relatively-boring opclass pushups).
>
> Here it is with some relatively-boring opclass pus
On Tue, Aug 8, 2017 at 6:18 PM, Rushabh Lathia wrote:
> Thanks Rajkumar for testing and reporting this.
>
>
> It seems like with we set the numParents and parents only for the
> dumpable objects (flagInhTables()). Current patch relies on the numParents
> and parents to get the root partition Table
Attaching newer patches rebased against the latest master head. Thanks !
Regards,
Amul
0001-Cleanup_v6.patch
Description: Binary data
0002-hash-partitioning_another_design-v16.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Jul 5, 2017 at 4:50 PM, Dilip Kumar wrote:
> On Mon, Jul 3, 2017 at 4:39 PM, amul sul wrote:
>> Thanks to catching this, fixed in the attached version.
>
> Few comments on the latest version.
>
Thanks for your review, please find my comment inline:
> 0001 looks
On Fri, Jun 23, 2017 at 11:19 AM, Yugo Nagata wrote:
> On Fri, 23 Jun 2017 13:41:15 +0900
> Yugo Nagata wrote:
>
>> On Tue, 6 Jun 2017 13:03:58 +0530
>> amul sul wrote:
>>
>>
>> > Updated patch attached.
>>
>> I looked into the latest patch
On Fri, Jun 23, 2017 at 10:11 AM, Yugo Nagata wrote:
> On Tue, 6 Jun 2017 13:03:58 +0530
> amul sul wrote:
>
>
>> Updated patch attached.
>
> I looked into the latest patch (v13) and have some comments
> althogh they might be trivial.
>
Thanks for your review.
On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote
wrote:
> On 2017/06/22 20:48, amul sul wrote:
>> Hi,
>>
>> While working on the another patch, I came across the case where
>> I need an auto generated partition for a mutil-column range partitioned
>> t
Hi,
While working on the another patch, I came across the case where
I need an auto generated partition for a mutil-column range partitioned
table having following range bound:
PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10)
PARTITION p2 FROM (10, 10) TO (10, UNBOUNDED)
PARTITION p3 FROM
On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote:
[...]
> I committed this with fixes for those issues, plus I renamed the macro
> to partition_bound_accepts_nulls, which I think is more clear.
>
partition_bound_accepts_nulls() will alway yield true for a range
partitioning case, because in Rel
On Wed, Jun 7, 2017 at 10:30 AM, Jeevan Ladhe
wrote:
>
>
>> IIUC, default partition constraints is simply NOT IN (> other sibling partitions>).
>> If constraint on the default partition refutes the new partition's
>> constraints that means we have overlapping partition, and perhaps
>> error.
>
>
>
On Wed, Jun 7, 2017 at 2:08 AM, Jeevan Ladhe
wrote:
[...]
>>
>> The code in check_default_allows_bound() to check whether the default
>> partition
>> has any rows that would fit new partition looks quite similar to the code
>> in
>> ATExecAttachPartition() checking whether all rows in the table be
Hi Dilip,
Thanks for review.
On Sat, Jun 3, 2017 at 6:54 PM, Dilip Kumar wrote:
> On Thu, May 25, 2017 at 9:59 AM, amul sul wrote:
>> On Mon, May 22, 2017 at 2:23 PM, amul sul wrote:
>>>
>>> Updated patch attached. Thanks a lot for review.
>>>
>> Mino
On Mon, May 22, 2017 at 2:23 PM, amul sul wrote:
>
> Updated patch attached. Thanks a lot for review.
>
Minor fix in the document, PFA.
Regards,
Amul
0002-hash-partitioning_another_design-v12.patch
Description: Binary data
0001-Cleanup_v4.patch
Description: Binary data
--
Sent
On Fri, May 19, 2017 at 10:35 PM, Robert Haas wrote:
> On Fri, May 19, 2017 at 5:32 AM, amul sul wrote:
>> Updated patch attached. 0001-patch rebased against latest head.
>> 0002-patch also incorporates code comments and error message changes
>> as per Robert's
On Wed, May 17, 2017 at 6:54 PM, Ashutosh Bapat
wrote:
[...]
>
> Comments on the tests
> +#ifdef USE_ASSERT_CHECKING
> +{
> +/*
> + * Hash partition bound stores modulus and remainder at
> + * b1->datums[i][0] and b1->datums[i][1] position respectively.
On Wed, May 17, 2017 at 11:11 AM, Ashutosh Bapat
wrote:
> On Wed, May 17, 2017 at 12:04 AM, amul sul wrote:
>> On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote:
>>> On Tue, May 16, 2017 at 4:22 PM, amul sul wrote:
>>>> v6 patch has bug in partition oid mapp
On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote:
> On Tue, May 16, 2017 at 4:22 PM, amul sul wrote:
>> v6 patch has bug in partition oid mapping and indexing, fixed in the
>> attached version.
>>
>> Now partition oids will be arranged in the ascending order of ha
On Tue, May 16, 2017 at 3:30 PM, amul sul wrote:
> On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat
> wrote:
> [...]
>>>>
>>>> +if (key->strategy == PARTITION_STRATEGY_HASH)
>>>> +{
>>>> +ndatums = nparts
On Tue, May 16, 2017 at 1:17 PM, Ashutosh Bapat
wrote:
> Hi,
> Here's patch with some cosmetic fixes to 0002, to be applied on top of 0002.
>
Thank you, included in v6 patch.
Regards,
Amul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat
wrote:
[...]
>>>
>>> +if (key->strategy == PARTITION_STRATEGY_HASH)
>>> +{
>>> +ndatums = nparts;
>>> +hbounds = (PartitionHashBound **) palloc(nparts *
>>> +
>>> sizeof(PartitionHashBound *));
>>> +
On Mon, May 15, 2017 at 9:13 PM, Robert Haas wrote:
> On Mon, May 15, 2017 at 6:57 AM, amul sul wrote:
>>> Collation is only relevant for ordering, not equality. Since hash
>>> opclasses provide only equality, not ordering, it's not relevant here.
>>> I'm
On Wed, May 10, 2017 at 10:13 PM, Robert Haas wrote:
> On Wed, May 10, 2017 at 8:34 AM, Ashutosh Bapat
> wrote:
>> Hash partitioning will partition the data based on the hash value of the
>> partition key. Does that require collation? Should we throw an error/warning
>> if
>> collation is specif
On Sat, May 13, 2017 at 12:11 PM, Dilip Kumar wrote:
> On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
>> Hi,
>>
>> Please find the following updated patches attached:
>
> I have done some testing with the new patch, most of the cases worked
> as per the expecta
On Fri, May 12, 2017 at 10:39 PM, Ashutosh Bapat
wrote:
> On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
>> Hi,
>>
>> Please find the following updated patches attached:
>>
>> 0001-Cleanup.patch : Does some cleanup and code refactoring required
>> for
On Thu, May 11, 2017 at 9:32 PM, Dilip Kumar wrote:
> On Wed, May 3, 2017 at 6:39 PM, amul sul wrote:
>> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>>
>>>I spent some time today looking at these patches. It seems like there
>>>is some more work still
On Wed, May 10, 2017 at 6:04 PM, Ashutosh Bapat
wrote:
> On Wed, May 3, 2017 at 6:39 PM, amul sul wrote:
>> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>>
>>>
>>> This is not yet a detailed review - I may be missing things, and
>>> review and co
On Tue, May 9, 2017 at 3:51 PM, Ashutosh Bapat
wrote:
> On Tue, May 9, 2017 at 2:59 PM, Amit Langote
> wrote:
>> Hi Amul,
>>
>> On 2017/05/09 16:13, amul sul wrote:
>>> Hi,
>>>
>>> Current pg_dump --exclude-table option excludes partitioned rela
Hi,
Current pg_dump --exclude-table option excludes partitioned relation
and dumps all its child relations and vice versa for --table option, which
I think is incorrect.
In this case we might need to explore all partitions and exclude or include
from dump according to given pg_dump option, attach
On Tue, May 2, 2017 at 9:33 PM, Rahila Syed wrote:
> Please find attached updated patch with review comments by Robert and Jeevan
> implemented.
>
Patch v8 got clean apply on latest head but server got crash at data
insert in the following test:
-- Create test table
CREATE TABLE test ( a int, b d
On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>I spent some time today looking at these patches. It seems like there
>is some more work still needed here to produce something committable
>regardless of which way we go, but I am inclined to think that Amul's
>patch is a better basis for wor
On Fri, Mar 3, 2017 at 5:00 PM, Greg Stark wrote:
> On 2 March 2017 at 13:03, amul sul wrote:
> > create table foo (a integer, b text) partition by hash (a);
> > create table foo1 partition of foo with (modulus 4, remainder 0);
> > create table foo2 partition of foo with (m
On Wed, Mar 1, 2017 at 3:50 PM, Yugo Nagata wrote:
> []
>
> I Agree that it is unavoidable partitions number in modulo hashing,
> > but we can do in other hashing technique. Have you had thought about
> > Linear hashing[1] or Consistent hashing[2]? This will allow us to
> > add/drop
> >
On Tue, Feb 28, 2017 at 8:03 PM, Yugo Nagata wrote:
> Hi all,
>
> Now we have a declarative partitioning, but hash partitioning is not
> implemented yet. Attached is a POC patch to add the hash partitioning
> feature. I know we will need more discussions about the syntax and other
> specifications
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Review of v7 patch:
- Patch applies to the top of master HEAD cleanl
About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch,
following test is already covered in alter_table.sql @ Line # 1918,
instead of this kindly add test for list_partition:
77 +-- cannot drop NOT NULL constraint of a range partition key column
78 +ALTER TABLE range_parted ALTER a DROP
Hi Amit,
Regarding following code in ATExecDropNotNull function, I don't see
any special check for RANGE partitioned, is it intended to have same
restriction for LIST partitioned too, I guess not?
/*
* If the table is a range partitioned table, check that the column is not
* in the pa
I see, thanks Amit.
Regards,
Amul
Sent from a mobile device. Please excuse brevity and tpyos.
Hi,
In following case, constraint exclusion not able prune partition (even
if function is immutable), is this know behaviour?
--CASE 1 : create table & insert data
create table foo_list (a integer, b text) partition by list (abs(a));
create table foo_list1 partition of foo_list for values in (0)
On Tue, Jan 10, 2017 at 7:09 AM, Jim Nasby wrote:
> On 1/9/17 7:22 AM, amul sul wrote:
>>
>> On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby
>> wrote:
>>>
>>>
>> [skipped...]
>>>
>>>
>>> Oh, hmm. So I guess if you do that when th
On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby wrote:
>
[skipped...]
>
> Oh, hmm. So I guess if you do that when the background process is idle it's
> the same as a close?
>
> I think we need some way to safeguard against accidental forkbombs for cases
> where users aren't intending to leave something
Hi,
I got server crash due to assert failure at ATTACHing overlap rang
partition, here is test case to reproduce this:
CREATE TABLE test_parent(a int) PARTITION BY RANGE (a);
CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES
FROM(100) TO(200);
CREATE TABLE test_parent_part1(a int
On Sat, Jan 7, 2017 at 2:06 PM, Andrew Borodin wrote:
> Hi!
>
> 2017-01-07 11:44 GMT+05:00 amul sul :
>
>> Changes:
>> 1. pg_background_launch renamed to pg_background_start
>> 2. pg_background_detach renamed to pg_background_close
>> 3. Added new api to
Hi all,
Attaching latest pg_background patch for review as per design proposed
on 22 Dec '16 with following minor changes in the api.
Changes:
1. pg_background_launch renamed to pg_background_start
2. pg_background_detach renamed to pg_background_close
3. Added new api to display previously launc
On Wed, Jan 4, 2017 at 2:57 PM, Andrew Borodin wrote:
> 2017-01-04 10:23 GMT+05:00 amul sul :
>> One more query, can we modify
>> BackgroundSessionStart()/BackgroundSession struct to get background
>> worker PID as well?
> I think since session always has a PID it&#x
On Tue, Jan 3, 2017 at 11:36 PM, Andrew Borodin wrote:
> 2017-01-03 19:39 GMT+05:00 Peter Eisentraut
> :
>>
>> On 1/3/17 1:26 AM, amul sul wrote:
>> > One more requirement for pg_background is session, command_qh,
>> > response_qh and worker_handle should be
On Fri, Dec 30, 2016 at 3:48 AM, Peter Eisentraut
wrote:
> On 12/16/16 10:38 AM, Andrew Borodin wrote:
>> 2016-12-16 20:17 GMT+05:00 Peter Eisentraut
>> :
And one more thing... Can we have BackgroundSessionExecute() splitted
into two parts: start query and wait for results?
It woul
detach
--
(1 row)
References :
[1]
https://www.postgresql.org/message-id/e1c2d331-ee6a-432d-e9f5-dcf85cffaf29%402ndquadrant.com.
Regards,
Amul Sul
0002-pg_background_worker_as_client_of_bgsession_trial.patch
Description: Binary data
--
Sent via pgsql-hackers mai
On Tue, Dec 20, 2016 at 12:21 AM, David Fetter wrote:
> On Thu, Nov 24, 2016 at 09:16:53AM +0530, amul sul wrote:
>> Hi All,
>>
>> I would like to take over pg_background patch and repost for
>> discussion and review.
>
> This looks great.
>
> Sadly,
On Thu, Dec 15, 2016 at 12:24 PM, Andrew Borodin wrote:
> 2016-12-15 0:30 GMT+05:00 Peter Eisentraut :
> TryBeginSession()?
What exactly would that do?
>>> Return status (success\failure) and session object, if a function succeeded.
>>>
>>> If there is max_connections exceeded, then
On Tue, Dec 13, 2016 at 2:05 PM, Andrew Borodin wrote:
> 2016-12-13 12:55 GMT+05:00 amul sul :
>> I think background-session code is not that much deviated from
>> pg_background code,
> It is not derived, though it is not much deviated. background sessions
> code do not hav
On Mon, Dec 12, 2016 at 10:47 PM, Andrew Borodin wrote:
> Hi!
>
Thanks a lot for your review.
> Just in case you'd like to include sleepsort as a test, here it is
> wrapped as a regression test(see attachment). But it has serious
> downside: it runs no less than 5 seconds.
>
> Also I'll list her
Hi All,
I would like to take over pg_background patch and repost for
discussion and review.
Initially Robert Haas has share this for parallelism demonstration[1]
and abandoned later with
summary of open issue[2] with this pg_background patch need to be
fixed, most of them seems to be
addressed in
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Patch v6 looks good to me, passing to committer.
Thanks !
The n
g this paragraph either, I'll leave the
decision to committer.
> I'll change the status to needs review.
The new status of this patch is: Ready for Committer
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
PostgreSQL also relies on the
operating system cache, it is unlikely that an allocation of more than
I may be wrong here, would like know your and/or community's thought
on this. Thanks.
Regards,
Amul Sul
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hackers ma
Kindly ignore this, i've added this note to original thread.
Sorry for noise.
Regards,
Amul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Guillaume,
With your v2 patch, -B options working as expected but --no-blobs
options is still unrecognized, this happens is because of you have
forgot to add entry for 'no-blobs' in long_options[] array.
Apart from this concern patch looks good to me. Thanks
Regards,
Amul
--
Sent via pgsql
On 31 Oct 2016 6:48 pm, "Tom Lane" wrote:
>
> amul sul writes:
> > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas
wrote:
> >> There's a comment in dumpExtension() that explains it.
>
> > Let me explain the case I'm trying to tackle. I have two o
On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote:
> On Thu, Oct 27, 2016 at 2:11 AM, amul sul wrote:
>> selectDumpableExtension() function skip
>> s dump of
>> built-in extensions in case of binary-upgrade only,
>> why not in normal
>> dump
>> ?
&
Hi
,
selectDumpableExtension() function skip
s dump of
built-in extensions in case of binary-upgrade only,
why not in normal
dump
?
Can't we assume those will already be installed in the target database
at restore
?
Thanks
&
Regards,
Amul
good to me, code in v6 does not differ much
from v4 patch. Ready for committer review. Thanks !
Regards,
Amul Sul
The new status of this patch is: Ready for Committer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
> Artur Zakirov writes:
>> - now DCH_cache_getnew() is called after parse_format(). Because now
>> parse_format() can raise an error and in the next attempt
>> DCH_cache_search() could return broken cache entry.
>
> I started looking at your 0001-t
On Fri, Sep 16, 2016 at 10:01 PM, Artur Zakirov
wrote:
> On 25.08.2016 13:26, amul sul wrote:
>>>
>>> Thanks. I've created the entry in
>>> https://commitfest.postgresql.org/10/713/
>>> . You can add yourself as a reviewer.
>>>
>>
>&
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Note for committer : There are unnecessary files (cube_1.out, cu
gt;>>
>>> Will be it a proper behaviour?
>>
>>
>>
>> Looks good to me, no one will complain if something working on PG but not
>> on Oracle.
>
>
> Thanks. I've created the entry in https://commitfest.postgresql.org/10/713/
> . You can add
wing line:
>>
>> 256 + prev_type;
>
>
>You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to
>execute such query:
>
>
>SELECT to_timestamp('---2000JUN', ' MON');
>
>
>Will be it a proper behaviour
1 - 100 of 138 matches
Mail list logo
