From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> > > How would you distinguish values in list partition for multiple
> > > columns? I mean for range partition, we are sure there will
> > > be either one value for each column, but for list it could
> > > be multiple and not fixed for each part
On Mon, Dec 8, 2014 at 3:42 PM, Rahila Syed wrote:
>
>>The important point to consider for this patch is the use of the additional
>> 2-bytes as uint16 in the block information structure to save the length of a
>> compressed
>>block, which may be compressed without its hole to achieve a double lev
>The important point to consider for this patch is the use of the
additional 2-bytes as uint16 in the block information structure to save the
length of a compressed
>block, which may be compressed without its hole to achieve a double level
of compression (image compressed without its hole). We may
On Mon, Dec 8, 2014 at 11:01 AM, Amit Langote
wrote:
> From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> Sent: Saturday, December 06, 2014 5:00 PM
> To: Robert Haas
> Cc: Amit Langote; Andres Freund; Alvaro Herrera; Bruce Momjian; Pg Hackers
> Subject: Re: [HACKERS] On partitioning
>
> On Fri,
On Mon, Dec 8, 2014 at 12:34 PM, Adam Brightwell
wrote:
> Michael,
>
>> This patch (https://commitfest.postgresql.org/action/patch_view?id=1616)
>> has not been updated in the commitfest app for two months, making its
>> progress hard to track.
>
>
> I believe that the mentioned patch should be co
On Sat, Dec 6, 2014 at 9:21 PM, Noah Misch wrote:
> On Thu, Dec 04, 2014 at 10:00:14AM +0530, Ashutosh Bapat wrote:
> > On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita <
> fujita.ets...@lab.ntt.co.jp> wrote:
> > > (2014/12/03 19:35), Ashutosh Bapat wrote:
> > >> On Tue, Dec 2, 2014 at 8:29 AM, Etsu
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
Sent: Saturday, December 06, 2014 5:06 PM
To: Robert Haas
Cc: Amit Langote; Andres Freund; Alvaro Herrera; Bruce Momjian; Pg Hackers
Subject: Re: [HACKERS] On partitioning
On Fri, Dec 5
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
Sent: Saturday, December 06, 2014 5:00 PM
To: Robert Haas
Cc: Amit Langote; Andres Freund; Alvaro Herrera; Bruce Momjian; Pg Hackers
Subject: Re: [HACKERS] On partitioning
On Fri, Dec 5, 2014 at 10:03 PM, Robert Haas wrote:
> On Tue, Dec 2, 20
Hi Robert,
> From: Robert Haas [mailto:robertmh...@gmail.com]
> On Tue, Dec 2, 2014 at 10:43 PM, Amit Langote
> wrote:
> >> So, we're going to support exactly two levels of partitioning?
> >> partitions with partissub=false and subpartitions with partissub=true?
> >> Why not support only one lev
On Sat, Dec 6, 2014 at 5:37 PM, Stephen Frost wrote:
>
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > 1. As the patch currently stands, it just shares the relevant
> > data (like relid, target list, block range each worker should
> > perform on etc.) to the worker and then worker receives th
On Mon, Dec 8, 2014 at 7:33 AM, Dilip kumar wrote:
> On 06 December 2014 20:01 Amit Kapila Wrote
>
> >I wanted to understand what exactly the above loop is doing.
>
>
>
> >a.
>
> >first of all the comment on top of it says "Some of the slot
>
> >are free, ...", if some slot is free, then why do yo
Michael,
This patch (https://commitfest.postgresql.org/action/patch_view?id=1616)
> has not been updated in the commitfest app for two months, making its
> progress hard to track.
I believe that the mentioned patch should be considered 'on hold' or
'dependent' upon the acceptance of the work tha
On Mon, Dec 8, 2014 at 11:30 AM, Simon Riggs wrote:
> * parameter should be SUSET - it doesn't *need* to be set only at
> server start since all records are independent of each other
Check.
> * ideally we'd like to be able to differentiate the types of usage.
> which then allows the user to contr
On 14/12/07 12:43, Bruce Momjian wrote:
> On Tue, Dec 2, 2014 at 03:13:07PM -0300, Alvaro Herrera wrote:
>> Robert Haas wrote:
>>> On Thu, Nov 27, 2014 at 11:43 PM, Ian Barwick wrote:
>>
A simple schedule to demonstrate this is available; execute from the
src/test/regress/ directory lik
> On Thu, Dec 4, 2014 at 8:37 PM, Michael Paquier wrote
> I pondered something that Andres mentioned upthread: we may not do the
>compression in WAL record only for blocks, but also at record level. Hence
>joining the two ideas together I think that we should definitely have
>a different
>GUC to co
(2014/12/07 2:02), David Fetter wrote:
On Thu, Dec 04, 2014 at 12:35:54PM +0900, Etsuro Fujita wrote:
But I think
there would be another idea. An example will be shown below. We show the
update commands below the ModifyTable node, not above the corresponding
ForeignScan nodes, so maybe less co
On 06 December 2014 20:01 Amit Kapila Wrote
>I wanted to understand what exactly the above loop is doing.
>a.
>first of all the comment on top of it says "Some of the slot
>are free, ...", if some slot is free, then why do you want
>to process the results? (Do you mean to say that *None* of
>the
On Mon, Dec 8, 2014 at 4:48 AM, John Gorman wrote:
> The attached patch applies cleanly against master and passes all regression
> tests including two new tests in guc.sql.
Please be sure to register your patch to the upcoming commit fest,
this way it will not fall into oblivion and will get some
On 08/12/14 00:56, Noah Misch wrote:
On Wed, Dec 03, 2014 at 11:54:38AM -0300, Alvaro Herrera wrote:
Pushed with some extra cosmetic tweaks.
The commit_ts test suite gives me the attached diff on a 32-bit MinGW build
running on 64-bit Windows Server 2003. I have not checked other Windows
conf
On Mon, Dec 8, 2014 at 10:18 AM, Petr Jelinek wrote:
> On 08/12/14 02:06, Petr Jelinek wrote:
>> Simon actually already committed something similar, so no need.
>>
>
> ...except for the removal of pause_at_recovery_target it seems, so I
> attached just that
Thanks! Removal of this parameter is get
Hi all,
I have been through a certain number of patches and marked the ones
that needed some love from their authors as returned with feedback (at
least the ones marked as such in the CF app), but you may have noticed
that :)
This email is a call to move on and close soon the CF currently open
an
On 08/12/14 02:06, Petr Jelinek wrote:
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek
wrote:
Ok this patch does that, along with the rename to
recovery_target_action and
addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b
On 08/12/14 02:03, Michael Paquier wrote:
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek wrote:
Ok this patch does that, along with the rename to recovery_target_action and
addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b8e33a8 are conflicting.
Simon actuall
On Mon, Dec 8, 2014 at 9:59 AM, Petr Jelinek wrote:
> Ok this patch does that, along with the rename to recovery_target_action and
> addition to the recovery.conf.sample.
This needs a rebase as at least da71632 and b8e33a8 are conflicting.
--
Michael
--
Sent via pgsql-hackers mailing list (pgs
On Sun, Nov 16, 2014 at 3:35 AM, Tomas Vondra wrote:
> Thanks for the link. I've been looking for a good dataset with such
> data, and this one is by far the best one.
>
> The current version of the patch supports only data types passed by
> value (i.e. no varlena types - text, ), which means it's
On 05/12/14 16:49, Robert Haas wrote:
On Thu, Dec 4, 2014 at 8:45 AM, Michael Paquier
wrote:
Here is patch which renames action_at_recovery_target to
recovery_target_action everywhere.
Thanks, Looks good to me.
A couple of things that would be good to document as well in
recovery-config.sgml:
On Fri, Oct 24, 2014 at 7:23 PM, Andres Freund wrote:
> On 2014-10-24 07:18:55 -0300, Alvaro Herrera wrote:
>> Yeah, this patch is a lot more debatable than the other one. I have
>> pushed the first one without changing the error message.
>
> We could just test for toc.dat and then emit the warni
On Sat, Dec 6, 2014 at 9:01 PM, Amit Kapila wrote:
> If you agree, then we should try to avoid this change in new behaviour.
Still seeing many concerns about this patch, so marking it as returned
with feedback. If possible, switching it to the next CF would be fine
I guess as this work is still be
On Sun, Dec 7, 2014 at 1:50 AM, Stephen Frost wrote:
> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
>> > I don't see any changes to the regression test files, were they
>> > forgotten in the patch? I would think that at least the view definition
>> > changes would require u
On Tue, Dec 2, 2014 at 2:14 PM, Jeff Davis wrote:
> On Sun, 2014-11-30 at 17:49 -0800, Peter Geoghegan wrote:
>> On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis wrote:
>> > I can also just move isReset there, and keep mem_allocated as a uint64.
>> > That way, if I find later that I want to track the
On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane wrote:
> I think what's likely missing here is a clear design for the raw parse
> tree representation (what's returned by the bison grammar). The patch
> seems to be trying to skate by without creating any new parse node types
> or fields, but that may we
On Wed, Dec 3, 2014 at 6:14 AM, Emre Hasegeli wrote:
>> Actually, there's a second large problem with this patch: blindly
>> iterating through all combinations of MCV and histogram entries makes the
>> runtime O(N^2) in the statistics target. I made up some test data (by
>> scanning my mail logs)
On Thu, Nov 27, 2014 at 10:16 AM, Bruce Momjian wrote:
> On Sat, Nov 8, 2014 at 05:56:00PM +0100, Andres Freund wrote:
>> On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
>> > Adding a similar
>> > level of burden to support a feature with a narrow use-case seems like
>> > a nonstarter from here.
>>
On Tue, Sep 9, 2014 at 12:47 AM, Heikki Linnakangas
wrote:
> On 09/08/2014 03:26 PM, Alexander Korotkov wrote:
>>
>> On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas
>> >>
>>> wrote:
>>
>>
>>> On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
>>>
On Mon, Sep 8, 2014 at 12:08 PM, Alexander
On Wed, Dec 3, 2014 at 4:03 PM, Michael Paquier
wrote:
> Ping? This patch is in a stale state for a couple of weeks and still
> marked as waiting on author for this CF.
Marked as returned with feedback.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On 20 October 2014 at 10:57, Jim Nasby wrote:
> Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
> lock on, with no retry. Presumably this should be a rare occurrence, but I
> think it's bad that we just assume that and won't warn the user if something
> bad is going on
On Wed, Dec 03, 2014 at 11:54:38AM -0300, Alvaro Herrera wrote:
> Pushed with some extra cosmetic tweaks.
The commit_ts test suite gives me the attached diff on a 32-bit MinGW build
running on 64-bit Windows Server 2003. I have not checked other Windows
configurations; the suite does pass on GNU/
On 12/07/2014 11:48 AM, John Gorman wrote:
>
> This patch implements the first wiki/Todo Configuration Files item
> "Consider normalizing fractions in postgresql.conf, perhaps using '%'".
>
> The "Fractions in GUC variables" discussion is here.
>
Oh, this is nice! Thanks for working on it.
-
This patch implements the first wiki/Todo Configuration Files item
"Consider normalizing fractions in postgresql.conf, perhaps using '%'".
The "Fractions in GUC variables" discussion is here.
http://www.postgresql.org/message-id/467132cf.9020...@enterprisedb.com
This patch implements expressing
Peter Eisentraut writes:
> My radical proposal therefore would have been to embrace this
> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
> relying on users interpreting the parameter names to indicate that
> changing them later may or may not have an effect. Unfortunatel
On 11/12/14 1:01 PM, Fujii Masao wrote:
> On Wed, Nov 5, 2014 at 1:22 AM, Peter Eisentraut wrote:
>> On 10/9/14 1:58 PM, Fujii Masao wrote:
>>> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
>>> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
>>> about applying the attac
On 12/07/2014 02:03 PM, Guillaume Lelarge wrote:
Hi,
I've been reading the FSM README file lately
(src/backend/storage/freespace/README), and I'm puzzled by one of the graph
(the binary tree structure of an FSM file). Here it is:
4
4 2
3 4 0 2<- This level represents heap pages
Hi,
I've been reading the FSM README file lately
(src/backend/storage/freespace/README), and I'm puzzled by one of the graph
(the binary tree structure of an FSM file). Here it is:
4
4 2
3 4 0 2<- This level represents heap pages
Shouldn't the last line be:
4 3 2 0
(ie, highest
On 4 December 2014 at 12:24, Simon Riggs wrote:
> On 3 December 2014 at 12:18, Atri Sharma wrote:
>
>> So the planner keeps all possibility satisfying plans, or it looks at the
>> possible conditions (like presence of foreign key for this case, for eg) and
>> then lets executor choose between the
44 matches
Mail list logo
