On 2017/09/15 1:37, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 7:56 AM, Amit Khandekar
> wrote:
>> On 14 September 2017 at 06:43, Amit Langote
>>> langote_amit...@lab.ntt.co.jp> wrote:
>>> Attached updated patch.
>>
>>
On 2017/09/15 4:43, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 8:06 AM, Ashutosh Bapat
> wrote:
>> I have few changes to multi-level expansion patch as per discussion in
>> earlier mails
>
> OK, I have committed
> 0002-Multi-level-partitioned-table-expansion.patch with a few cosmetic
> changes.
On 2017/09/15 10:55, David Rowley wrote:
> On 21 August 2017 at 18:37, Amit Langote
> wrote:
>> I've been working on implementing a way to perform plan-time
>> partition-pruning that is hopefully faster than the current method of
>> using constraint exclusion to
Hi Dilip,
Thanks for looking at the patch.
On 2017/09/15 13:43, Dilip Kumar wrote:
> On Wed, Sep 6, 2017 at 4:08 PM, Amit Langote
>> [PATCH 2/5] WIP: planner-side changes for partition-pruning
>>
>> This patch adds a stub get_partitions_for_keys in partition.c with a
>
On 2017/09/15 0:59, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 4:03 AM, Jeevan Ladhe
> wrote:
>> Thanks Amit for reviewing.
>>> Patch looks fine to me. By the way, why don't we just say "Can we skip
>>> scanning part_rel?" in the comment before the newly added call to
>>> PartConstraintImpliedB
Hi.
On 2017/08/28 18:28, Kyotaro HORIGUCHI wrote:
> << the following is another topic >>
>
BTW, in the partitioned table case, the parent is always locked first
using an AccessExclusiveLock. There are other considerations in that case
such as needing to recreate the partition desc
On 2017/09/15 15:36, Amit Langote wrote:
> The fact that
> parent is locked after the child and with ShareUpdateExclusiveLock instead
> of AccessExclusiveLock, we observe this race condition when SELECTing from
> the parent.
Oops, I meant "parent table is locked with AccessSha
On 2017/09/14 16:00, Michael Paquier wrote:
> On Wed, Sep 13, 2017 at 4:43 PM, Amit Langote
> wrote:
>> Sure, no problem.
>
> OK, I took a closer look at all patches, but did not run any manual
> tests to test the compression except some stuff with
> wal_consistency_c
On 2017/09/15 11:16, Amit Langote wrote:
> I will post rebased patches later today, although I think the overall
> design of the patch on the planner side of things is not quite there yet.
> Of course, your and others' feedback is greatly welcome.
Rebased patches attached.
On Fri, Sep 15, 2017 at 9:20 PM, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 8:30 AM, Ashutosh Bapat
> wrote:
>> LGTM. The patch applies cleanly on the current HEAD, compiles (small
>> bit in regress.c requires compilation), and make check passes. Marking
>> this as "ready for committer".
>
> Co
On Sat, Sep 16, 2017 at 12:59 AM, Robert Haas wrote:
> On Fri, Sep 15, 2017 at 2:00 AM, Amit Langote
> wrote:
>> I wonder if we should call check_default_allows_bound() from
>> ATExecAttachPartition(), too, instead of validating updated default
>> pa
On Sat, Sep 16, 2017 at 4:04 AM, Robert Haas wrote:
> On Fri, Sep 15, 2017 at 4:50 AM, Amit Langote
> wrote:
>> Rebased patches attached. Because Dilip complained earlier today about
>> clauses of the form (const op var) not causing partition-pruning, I've
>> add
Hi.
Trying to catch up.
On 2017/09/25 13:43, Michael Paquier wrote:
> On Sun, Sep 24, 2017 at 2:25 PM, Amit Kapila wrote:
>> Added and updated the comments for both btree and hash index patches.
>
> I don't have real complaints about this patch, this looks fine to me.
>
> +* Currently, the
On 2017/09/25 12:10, Michael Paquier wrote:
> On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote:
>> Somebody inserted this into vacuum.c's get_rel_oids():
>>
>> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
>> if (!HeapTupleIsValid(tuple))
>> elog(ERROR, "cach
Hi Dilip.
Thanks for looking at the patches and the comments.
On 2017/09/16 18:43, Dilip Kumar wrote:
> On Fri, Sep 15, 2017 at 2:20 PM, Amit Langote
> wrote:
>> On 2017/09/15 11:16, Amit Langote wrote:
>
> Thanks for the updated patch. I was going through the logic of
>
On 2017/09/25 18:37, Michael Paquier wrote:
> On Mon, Sep 25, 2017 at 4:42 PM, Amit Langote
> wrote:
>> On 2017/09/25 12:10, Michael Paquier wrote:
>> Hmm, I'm not sure if we need to lock the partitions, too. Locks taken by
>> find_all_inheritors() will be
On 2017/09/26 9:51, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier
> wrote:
>> On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane wrote:
>>> Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch.
>>> My thought about fixing it was to pass a null RangeVar when
On 2017/09/14 16:13, Amit Langote wrote:
> Hi.
>
> It seems to me that some of the code in partition.c is better placed
> somewhere under the executor directory. There was even a suggestion
> recently [1] to introduce a execPartition.c to house some code around
> tuple-routing.
On 2017/09/26 11:34, Amit Kapila wrote:
> On Mon, Sep 25, 2017 at 12:18 PM, Amit Langote wrote:
>> So, ISTM, comments that the patches add should all say that setting the
>> meta pages' pd_lower to the correct value helps to pass those pages to
>> xlog.c as compress
On 2017/09/26 12:17, Michael Paquier wrote:
> On Mon, Sep 25, 2017 at 3:48 PM, Amit Langote wrote:
>> So, ISTM, comments that the patches add should all say that setting the
>> meta pages' pd_lower to the correct value helps to pass those pages to
>> xlog.c as compress
On 2017/09/26 16:30, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 4:22 PM, Amit Langote
> wrote:
>>> Except that small thing, the patches do their duty.
>>
>> Thanks, revised patches attached.
>
> Cool, let's switch it back to a ready for committer stat
On 2017/09/16 1:57, Amit Langote wrote:
> On Sat, Sep 16, 2017 at 12:59 AM, Robert Haas wrote:
>> I believe the intended advantage of the current system is that if you
>> specify multiple operations in a single ALTER TABLE command, you only
>> do one scan rather than hav
On 2017/09/26 11:14, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 10:55 AM, Amit Langote wrote:
>> On 2017/09/26 9:51, Michael Paquier wrote:
>>> On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier wrote:
>>>> Something like that looks like a good compromise for
On 2017/09/26 11:12, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 10:54 AM, Amit Langote
> wrote:
>> I think that's right, although, I don't see any new RangeVar created under
>> vacuum() at the moment. Maybe, you're referring to the Nathan's patch
&g
On 2017/09/25 20:21, Dilip Kumar wrote:
> On Mon, Sep 25, 2017 at 3:34 PM, Amit Langote
> wrote:
>
>> Thanks for looking at the patches and the comments.
>
>> It's not clear to me whether get_rel_partitions() itself, as it is, is
>> callable from outside
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 other CommitFest
>> entries doesn't account for hash partitions
Hi David,
On 2017/09/27 6:04, David Rowley wrote:
> On 25 September 2017 at 23:04, Amit Langote
> wrote:
>> By the way, I'm now rebasing these patches on top of [1] and will try to
>> merge your refactoring patch in some appropriate way. Will post more
>&
Hi Jesper.
Firstly, thanks for looking at the patch.
On 2017/09/26 22:00, Jesper Pedersen wrote:
> Hi Amit,
>
> On 09/15/2017 04:50 AM, Amit Langote wrote:
>> On 2017/09/15 11:16, Amit Langote wrote:
>>> I will post rebased patches later today, although I think the o
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 I thought it would be better to keep
>>> MODULUS and REMAINDER in caps, if CREATE TABLE was in caps too in order to
>>> highlight
On 2017/09/21 12:42, Robert Haas wrote:
> Associate partitioning information with each RelOptInfo.
>
> This is not used for anything yet, but it is necessary infrastructure
> for partition-wise join and for partition pruning without constraint
> exclusion.
>
> Ashutosh Ba
Sorry, I meant to say PartitionSchem"e"Data in subject.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks Michael for working on this.
On 2017/09/27 11:28, Michael Paquier wrote:
> Hi all,
>
> I have been looking more closely at the problem in $subject, that I
> have mentioned a couple of times, like here:
> https://www.postgresql.org/message-id/cab7npqqa37oune_rjzpmwc4exqalx9f27-ma_-rsfl_3mj+
On 2017/09/28 16:13, Ashutosh Bapat wrote:
> On Thu, Sep 28, 2017 at 11:47 AM, Amit Langote wrote:
>> On 2017/09/21 12:42, Robert Haas wrote:
>>> Associate partitioning information with each RelOptInfo.
>>>
>>> This is not used for anything yet, but it is necess
On 2017/09/28 13:58, Dilip Kumar wrote:
> On Wed, Sep 27, 2017 at 6:52 AM, Amit Langote
> wrote:
>
> I was looking into the latest patch set, seems like we can reuse some
> more code between this path and runtime pruning[1]
>
> + foreach(lc1, matchedclauses[i])
> + {
>
On 2017/09/28 22:29, Jesper Pedersen wrote:
> On 09/28/2017 09:19 AM, Maksim Milyutin wrote:
>>> E.g. "No partition constraint" vs. "Partition constraint:
>>> satisfies_hash_partition(...)".
>>
>> I also noticed ambiguity in printing "No partition constraint" in
>> non-verbose mode and "Partition c
On 2017/09/28 22:19, Maksim Milyutin wrote:
> I also noticed ambiguity in printing "No partition constraint" in
> non-verbose mode and "Partition constraint:..." in verbose one for
> partition tables regardless of the type of partition.
> Attached small patch removes any output about partition cons
On 2017/09/30 1:28, Robert Haas wrote:
> On Thu, Sep 28, 2017 at 5:16 AM, David Rowley
> wrote:
>> I'd imagine, for
>> each partition key, you'd want to store a Datum with the minimum and
>> maximum possible value based on the quals processed. If either the
>> minimum or maximum is still set to NU
On 2017/10/03 7:16, Michael Paquier wrote:
> On Tue, Oct 3, 2017 at 1:23 AM, Alexander Korotkov
> wrote:
>> On Mon, Oct 2, 2017 at 6:57 PM, Tom Lane wrote:
>>>
>>> Daniel Gustafsson writes:
Thanks to everyone who participated, and to everyone who have responded
to my
nagging via t
Hi David.
Thanks a lot for your review comments and sorry it took me a while to reply.
On 2017/09/28 18:16, David Rowley wrote:
> On 27 September 2017 at 14:22, Amit Langote
> wrote:
>> - 0001 includes refactoring that Dilip proposed upthread [1] (added him as
>> an au
On Wed, Jul 22, 2015 at 8:19 PM, Alvaro Herrera
wrote:
>
> Not sure what Jim meant. Maybe he meant to be aware of when spilling to
> disk happens? Obviously, things become slower, so maybe you need to
> consider it for progress reporting purposes.
>
Perhaps the m_w_m determines how many dead tu
On 2015-07-16 PM 04:03, Jeff Janes wrote:
> On Wed, Jul 15, 2015 at 8:44 AM, Heikki Linnakangas wrote:
>
>>
>> Both. Here's the patch.
>>
>> Previously, LWLockAcquireWithVar set the variable associated with the lock
>> atomically with acquiring it. Before the lwlock-scalability changes, that
>> w
On Tue, Jul 28, 2015 at 12:21 AM, Heikki Linnakangas wrote:
>
> Thanks, I've pushed this, as well a fix to similar failure from B-tree
> vacuum that Amit Langote reported in the other thread.
>
Thanks Heikki and sorry I didn't notice this new thread.
Regards,
Amit
--
KaiGai-san,
On 2015-07-27 PM 11:07, Kouhei Kaigai wrote:
>
> Append
>--> Funnel
> --> PartialSeqScan on rel1 (num_workers = 4)
>--> Funnel
> --> PartialSeqScan on rel2 (num_workers = 8)
>--> SeqScan on rel3
>
> shall be rewritten to
> Funnel
> --> PartialSeq
Attached fixes a minor typo:
s/custom/foreign/g
Thanks,
Amit
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c
index ea185d4..ee8710d 100644
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend/optimizer/plan/setrefs.c
@@ -1099,7 +1099,7 @@ set_forei
KaiGai-san,
On 2015-07-28 PM 09:58, Kouhei Kaigai wrote:
>>
>> From my understanding of parallel seqscan patch, each worker's
>> PartialSeqScan asks for a block to scan using a shared parallel heap scan
>> descriptor that effectively keeps track of division of work among
>> PartialSeqScans in ter
On 2015-07-29 AM 11:02, Kouhei Kaigai wrote:
>>
>> ...
>> synchronous Append path vs. parallel asynchronous Append with Funnel
>> (below/above?) it. I guess the asynchronous version would always be
>> cheaper. So, even if we end up with non-parallel sub-plans do we still add
>> a Funnel to make App
Hi,
Attached fixes a typo:
- * no permanent tables cannot reference unlogged ones.
+ * permanent tables cannot reference unlogged ones.
Thanks,
Amit
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 1c7eded..b459b1e 100644
--- a/src/backend/commands/t
On 2015-08-03 PM 09:24, Ashutosh Bapat wrote:
> On Sat, Aug 1, 2015 at 12:18 AM, Robert Haas wrote:
>>
>> OK, sure. But let's make sure postgres_fdw gets a server-level option
>> to control this.
>>
>>
> For postgres_fdw it's a boolean server-level option 'twophase_compliant'
> (suggestions for n
On 2015-08-04 AM 02:57, Peter Geoghegan wrote:
> On Mon, Aug 3, 2015 at 8:53 AM, Geoff Winkless wrote:
>> If I create a copy of the table using
>>
>> CREATE mytab (LIKE brokentab INCLUDING ALL);
>> INSERT INTO mytab SELECT * FROM brokentab;
>
> Also, did you drop any columns from the original "br
On 2015-08-04 PM 05:58, Geoff Winkless wrote:
>
> ​Although it seems Amit has defined the problem better than I could, so
> this is a bit late to the party (!), yes, the table had been ALTERed after
> it was created (looking back through the history, that modification
> included at least one DROP
On 2015-08-05 AM 06:11, Robert Haas wrote:
> On Mon, Aug 3, 2015 at 8:19 PM, Amit Langote
> wrote:
>> On 2015-08-03 PM 09:24, Ashutosh Bapat wrote:
>>> For postgres_fdw it's a boolean server-level option 'twophase_compliant'
>>> (suggestions for name
On 2015-08-05 AM 06:44, Peter Geoghegan wrote:
> On Tue, Aug 4, 2015 at 2:29 AM, Amit Langote
> wrote:
>> Perhaps, it may have to do with how EXCLUDED pseudo-rel's targetlist is
>> manipulated through parse-plan stage?
>
> I think so, yes.
>
> I'll look
Hi Thom,
On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown wrote:
>
>
> Wow, didn't expect to see that email this morning.
>
> A very quick test:
>
> CREATE TABLE purchases (purchase_id serial, purchase_time timestamp, item
> text) partition by range on ((extract(year from
> purchase_time)),(extract(mo
On 2015-08-18 PM 10:43, David Fetter wrote:
>>
>> After the first command is done, the second command would take exclusive
>> lock on table_name, scan the table to check if it contains any values
>> outside the boundaries defined by FOR VALUES clause defined previously,
>> throw error if so, mark a
On 2015-08-19 AM 02:57, Marc Mamin wrote:
>> 2. Creating a partition of a partitioned table
>>
>> CREATE TABLE table_name
>> PARTITION OF partitioned_table_name
>> FOR VALUES values_spec;
>>
>> Where values_spec is:
>>
>> listvalues: [IN] (val1, ...)
>>
>
> Would it make sense to allow one complem
On 2015-08-19 PM 09:23, Simon Riggs wrote:
> On 18 August 2015 at 11:30, Amit Langote
> wrote:
>
>>
>> There is no need to define tuple routing triggers. CopyFrom() and
>> ExecInsert() determine target partition just before performing
>> heap_insert() and Exe
On 2015-08-20 AM 05:10, Josh Berkus wrote:
> On 08/19/2015 04:59 AM, Simon Riggs wrote:
>> I like the idea of a regular partitioning step because it is how you
>> design such tables - "lets use monthly partitions".
>>
>> This gives sanely terse syntax, rather than specifying pages and pages
>> of e
On 2015-08-20 PM 06:27, Pavan Deolasee wrote:
> On Tue, Aug 18, 2015 at 4:00 PM, Amit Langote > wrote:
>>
>> PARTITION BY LIST ON (name)
>> PARTITION BY RANGE ON (year, month)
>>
>> PARTITION BY LIST ON ((lower(left(name, 2)))
>> PARTITION BY RANGE ON ((ex
On 2015-08-20 PM 06:34, Simon Riggs wrote:
> On 20 August 2015 at 10:10, Amit Langote
> wrote:
>
>> On 2015-08-20 AM 05:10, Josh Berkus wrote:
>>>>PARTITION BY RANGE ON (columns) INCREMENT BY (INTERVAL '1 month' )
>>>> START WITH value;
>
On 2015-08-19 AM 02:59, Corey Huinker wrote:
>
> Quick thoughts borne of years of slugging it out with partitions on Oracle:
>
> - Finally!!!
>
> - Your range partitioning will need to express exclusive/inclusive bounds,
> or go to the Oracle model where every partition is a cascading "v
On 2015-08-19 PM 09:52, David Fetter wrote:
> On Wed, Aug 19, 2015 at 04:30:39PM +0900, Amit Langote wrote:
>>>
>>> One small change to make this part more efficient:
>>>
>>> 1. Take the access exclusive lock on table_name.
>>> 2. Check for a match
On 2015-08-20 PM 10:19, David Fetter wrote:
> On Thu, Aug 20, 2015 at 06:58:24PM +0900, Amit Langote wrote:
>>
>> Ah, I understand the point of parameterization (TRUST). Seems like it
>> would be good to have with appropriate documentation of the same. Perhaps,
>> it m
On 2015-08-21 AM 06:27, David Fetter wrote:
>> By the last sentence, do you mean only UPDATEs to the partition key that
>> cause rows to jump partitions or simply any UPDATEs to the partition key?
>
> I don't know what Simon had in mind, but it seems to me that we have
> the following in descendi
Hello,
On 2015-08-30 PM 07:58, My Life wrote:
> Hi, everyone! I'd like to propose a postgres partition implementation.
> First, I would show the design to everyone, and talk about it. If we think
> the design is not very bad, and can be commit to the PostgreSQL baseline,
> then I will post the co
Hello,
On 2015-08-30 PM 10:42, My Life wrote:
>
> For partitioned table's scan action, and JOIN action, we implemented
> a plan node named 'PartitionExpand'. the plan node can expand the
> partitioned table scan node into a list of partitions according to
> the filter and conditions. and it can
On 2015-09-02 PM 01:28, Amit Kapila wrote:
>> On Tue, Sep 1, 2015 at 9:48 PM, Robert Haas wrote:
>>>
>>> I'm not averse to making the "connect to the remote nodes" part of
>>> this solution use something other than the FDW infrastructure at some
>>> point in time if somebody's prepared to build so
On 2015-09-02 PM 03:25, Amit Kapila wrote:
> On Wed, Sep 2, 2015 at 11:35 AM, Etsuro Fujita
>>
>> The UPDATE/DELETE pushdown, which I've proposed, would ensure the sane
>> behaviour for inherited UPDATEs/DELETEs, as existing non-pushed-down
>> UPDATE/DELETE does, because inheritance_planner guaran
On 2015-09-02 PM 04:07, Albe Laurenz wrote:
> Amit Langote wrote:
>> On 2015-09-02 PM 03:25, Amit Kapila wrote:
>>> Will it handle deadlocks across different table partitions. Consider
>>> a case as below:
>>>
>>> T1
>>> 1. Updates row R1 of
Peter,
On 2015-08-11 AM 07:37, Peter Geoghegan wrote:
> What I'm going to do is roll this into my own pending patch to fix the
> issue with wholerow vars, which is also down to a problem with the
> excluded targetlist initially generated by calling expandRelAttrs().
> Andres might want to take an
On 2015-09-02 PM 05:07, Etsuro Fujita wrote:
> On 2015/09/02 16:40, Amit Langote wrote:
>> On 2015-09-02 PM 04:07, Albe Laurenz wrote:
>>>
>>> That would only hold for a single query, right?
>>>
>>> If 1. and 2. in the above example come from diff
On 2015-09-02 PM 06:41, Amit Langote wrote:
>
> I think Albe may have a point here...
>
> Even inherited updates case appears to cause a deadlock if they are in
> different queries. Demonstrated below:
>
> -- setup
> CREATE TABLE t(a int);
> CREATE TABLE t1() INH
On 9/3/2015 5:49 PM, Tatsuo Ishii wrote:
>
> However I inserted data *after* creating index, the value is
> different.
> VACUUM;
> VACUUM
> SELECT * FROM brin_revmap_data(get_raw_page('brinidx', 1)) WHERE pages !=
> '(0,0)'::tid;
> pages
> ---
> (2,1)
> (2,2)
> (2,3)
> (2,4)
> (4 rows)
On 9/4/2015 9:22 AM, Tatsuo Ishii wrote:
>>
>> In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan()
>> using heap_setscanlimits(). One can imagine how the above heap finish
>> criteria might not work as expected.
>
> What scares me is:
>
> 1) the bug will not be found unless
On 9/4/2015 8:28 AM, Tatsuo Ishii wrote:
>>
>> Attached hack fixes the symptom but perhaps not the correct fix for this.
>
> Why can't we fix summarize_range() in brin.c:
>
> IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true,
>
On 9/4/2015 12:01 PM, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 9/4/2015 9:22 AM, Tatsuo Ishii wrote:
>>>
>>> 3) I wonder if other index type is suffered by this type of bug.
>>>
>>
>> About 3, it seems unlikely. Both the IndexBuild
On 9/4/2015 1:33 PM, Tatsuo Ishii wrote:
>> Ah, it did cross my mind to the fix it in brin.c but was not sure. I did
>> it that way in the attached patch.
>
> Amit,
>
> I have looked into your patch and am a little bit worried because it
> calls RelationGetNumberOfBlocks() which is an expensive f
On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
>> One thing I imagine we could do is to change the signature of
>> summrize_range() to also include heapNumBlks which its (only) caller
>> brinsummarize() already computes. It will look like:
>>
>> static void summarize_range(IndexInfo *indexInfo, BrinBuild
Sorry about the long delay in replying, to this message or the others
posted in the last few days. I should have notified in advance of my
vacation with rather limited Internet access.
On 2015-08-26 PM 11:00, Simon Riggs wrote:
> On 18 August 2015 at 11:30, Amit Langote
>
>> 3.
On Saturday, September 5, 2015, Tatsuo Ishii wrote:
> > Tatsuo Ishii wrote:
> >> > On 9/4/2015 2:04 PM, Tatsuo Ishii wrote:
> >> >>> One thing I imagine we could do is to change the signature of
> >> >>> summrize_range() to also include heapNumBlks which its (only) caller
> >> >>> brinsummarize()
Hi,
There is a possible typo in src/backend/catalog/README and the
attached fixes it.
--
Amit
diff --git a/src/backend/catalog/README b/src/backend/catalog/README
index fce01ea..7e0ddf3 100644
--- a/src/backend/catalog/README
+++ b/src/backend/catalog/README
@@ -92,7 +92,7 @@ them. Thus, the var
On Mon, Jan 27, 2014 at 11:18 PM, Amit Langote wrote:
> On Mon, Jan 13, 2014 at 2:50 PM, Amit Kapila wrote:
>> I have extended test (contrib) module dsm_demo such that now user
>> can specify during dsm_demo_create the lifespan of segment.
>> The values it can accept are 0 o
On Mon, Jan 13, 2014 at 2:50 PM, Amit Kapila wrote:
> I have extended test (contrib) module dsm_demo such that now user
> can specify during dsm_demo_create the lifespan of segment.
> The values it can accept are 0 or 1. Default value is 0.
> 0 -- means segment will be accessible for session life
On Tue, Jan 28, 2014 at 1:41 PM, Amit Kapila wrote:
> On Mon, Jan 27, 2014 at 7:48 PM, Amit Langote wrote:
>> On Mon, Jan 13, 2014 at 2:50 PM, Amit Kapila wrote:
>>> I have extended test (contrib) module dsm_demo such that now user
>>> can specify during dsm_demo_cre
Hi Anirudh,
On Fri, Jan 31, 2014 at 12:23 PM, Anirudh wrote:
> Hello everyone,
>
> My name is Anirudh Subramanian and I am a graduate student in Computer
> Science. I would like to participate in Google Summer of Code and would like
> to contribute to postgresql. I am not familiar with the postgr
In src/backend/storage/freespace/freespace.c,
*
* MaxFSMRequestSize depends on the architecture and BLCKSZ, but assuming
* default 8k BLCKSZ, and that MaxFSMRequestSize is 24 bytes, the categories
* look like this
*
Is "24 bytes" a typo considering that
#define MaxFSMRequestSize MaxHeapTu
Amul,
On Thu, Feb 13, 2014 at 5:59 PM, amul sul wrote:
> I have basic questions,
>
> 1. Condition testing of GUC_check_errdetail_string or other GUC_* is
> needed, even if we resting it?
A few lines before this conditional test, there is a call to the hook
function (using the check_hook funct
Hi,
Should "background writer" in the following comment be "checkpointer" post-9.2?
src/backend/access/transam/xlog.c
/*
* Statistics for current checkpoint are collected in this global struct.
* Because only the background writer or a stand-alone backend can perform
* checkpoints, this will
On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko wrote:
>
> xlog.c:6177
> if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
> ereport(ERROR,
> (errmsg("hot standby is not possible because wal_level was not
>
> So we have to start and stop standby server with changed
> wal_leve
On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote wrote:
> On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko wrote:
>
>>
>> xlog.c:6177
>> if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
>> ereport(ERROR,
>> (errmsg("hot standby is
e has to do with the following commit:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bd5ab4b28745605493ab7061724ba0375ee9593a
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
My previous report and subsequently commit 70d44dd apparently missed to
notice a few more cross-references to set_append_rel_pathlist where
set_append_rel_size is now meant. Attached fixes it.
Thanks,
Amit
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
i
On 2015/09/28 13:31, David Rowley wrote:
> I've been spending time working on allowing the planner to perform
> aggregation before the final join relation is created.
>
...
>
> The patch is however so far capable of giving us extremely nice performance
> improvements for some (likely artificial) q
On 2015/09/28 17:04, David Rowley wrote:
> On 28 September 2015 at 20:36, Amit Langote
> wrote:
>
>>
>> Did you perhaps attach a version of the patch you didn't intend to?
>>
>
> Oops. It seems so.
>
> Please find the correct version attached.
Thank
On 2015/09/28 20:58, David Rowley wrote:
> On 28 September 2015 at 23:17, Amit Langote
> wrote:
>> Moreover, would partial aggregation work below Append?
>>
>
> Do you mean for cases like:
>
> create table a as select x.x a from generate_series(1,100) x(x);
On 2015/10/02 15:38, Fujii Masao wrote:
>
> +uint32 progress_param[N_PROGRESS_PARAM];
>
> Why did you use an array to store the progress information of VACUUM?
> I think that it's better to use separate specific variables for them for
> better code readability, for example, variables scanned_
Came across a couple of unclear comments about functions returning
ObjectAddress. Attached fixes them.
Thanks,
Amit
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 7668c9d..403582c 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/table
On 2015/10/16 0:21, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Came across a couple of unclear comments about functions returning
>> ObjectAddress. Attached fixes them.
>
> Thanks, pushed to 9.5 and master.
Thanks, Alvaro.
Regards,
Amit
--
Sent via pgsql-hacker
Attached fixes the following in comment above ExecCheckIndexConstraints:
s/no no conflict/no conflict/g
Thanks,
Amit
diff --git a/src/backend/executor/execIndexing.c b/src/backend/executor/execIndexing.c
index 7299329..8f1b058 100644
--- a/src/backend/executor/execIndexing.c
+++ b/src/backend/exe
On Wednesday, 21 October 2015, Thom Brown wrote:
> On 18 August 2015 at 12:23, Amit Langote > wrote:
> > Hi Thom,
> >
> > On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown > wrote:
> >>
> >>
> >> Wow, didn't expect to see that email this m
Hi,
This may just be nitpicking but I noticed that ATWrongRelkindError() could
emit a better message in case of such errors during ALTER COLUMN DEFAULT
and ALTER COLUMN SET STORAGE than "%s is of the wrong type" which is what
it would emit now. Just need to add a couple of cases to the switch the
701 - 800 of 1334 matches
Mail list logo
