Hello Peter,
Here is a review:
The version 2 of the patch applies cleanly on current head.
The ability to generate and reuse a temporary installation for different
tests looks quite useful, thus putting install out of pg_regress and in
make seems reasonnable.
However I'm wondering whether
Re: Fabrízio de Royes Mello 2014-06-25
> On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane wrote:
> > Would like that, but I'm not sure what pgindent will do with the //
> > comments. It's been on my to-do list to switch all the comments to C89
> > style and then pgindent it, but I don't see myself get
On 8/31/14 12:40 AM, Dobes Vandermeer wrote:
> The background workers can apparently only connect to a single database
> at a time, but I want to expose all the databases via the API.
I think the term "background worker" should be taken as a hint that
"foreground protocol endpoint" was not one of
On 8/30/14 2:26 AM, Jeff Janes wrote:
> But there cases were people use COPY in a loop with a small amount of
> data in each statement.
What would be the reason for doing that?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Tue, Aug 26, 2014 at 9:43 AM, Michael Paquier
wrote:
> On Tue, Aug 19, 2014 at 2:49 PM, Michael Paquier
> wrote:
>> On Mon, Aug 18, 2014 at 4:01 PM, Michael Paquier
>> wrote:
>>> On Mon, Aug 18, 2014 at 3:48 PM, Fujii Masao wrote:
On Mon, Aug 18, 2014 at 2:38 PM, Michael Paquier
w
Em domingo, 31 de agosto de 2014, Christoph Berg escreveu:
> Re: Fabrízio de Royes Mello 2014-06-25
> >
> > On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane > wrote:
> > > Would like that, but I'm not sure what pgindent will do with the //
> > > comments. It's been on my to-do list to switch all the
Em domingo, 31 de agosto de 2014, Peter Eisentraut
escreveu:
> On 8/31/14 12:40 AM, Dobes Vandermeer wrote:
> > The background workers can apparently only connect to a single database
> > at a time, but I want to expose all the databases via the API.
>
> I think the term "background worker" shoul
On Tue, August 26, 2014 14:24, Andrew Gierth wrote:
>> "Erik" == Erik Rijkers writes:
>
> >> They apply cleanly for me at 2bde297 whether with git apply or
> >> patch, except for the contrib one (which you don't need unless you
> >> want to run the contrib regression tests without applying
On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers wrote:
> On Tue, August 26, 2014 14:24, Andrew Gierth wrote:
> >> "Erik" == Erik Rijkers writes:
> >
> > >> They apply cleanly for me at 2bde297 whether with git apply or
> > >> patch, except for the contrib one (which you don't need unless you
On 2014-08-31 21:09:59 +0530, Atri Sharma wrote:
> On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers wrote:
> > I have found that the "unrecognized node type" error is caused by:
It's a warning, not an error, right?
> > shared_preload_libraries = pg_stat_statements
> >
> > in postgresql.conf (as my
# actual new tmp installation
.tmp_install:
$(RM) ./.tmp_install.*
$(RM) -r ./tmp_install
# create tmp installation...
touch $@
# tmp installation for the nonce
.tmp_install.$(MAKE_NONCE): .tmp_install
touch $@
Oops, I got it wrong, the install woul
On Sunday, August 31, 2014, Andres Freund wrote:
> On 2014-08-31 21:09:59 +0530, Atri Sharma wrote:
> > On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers > wrote:
> > > I have found that the "unrecognized node type" error is caused by:
>
> It's a warning, not an error, right?
>
> > > shared_preload_
Bruce Momjian writes:
> I have developed the attached patch to warn about column reordering in
> this odd case. The patch mentions the reordering of c:
> NOTICE: merging column "a" with inherited definition
> NOTICE: merging column "c" with inherited definition; column moved
> ea
On 30 August 2014 18:24, Tom Lane wrote:
>> 3. I am thinking about name - I don't think so varwidth_bucket is correct
>> -- in relation to name "width_bucket" ... what about "range_bucket" or
>> "scope_bucket" ?
>
> Neither of those seem like improvements from here. I agree with the
> objections
Tom Lane-2 wrote
> Bruce Momjian <
> bruce@
> > writes:
>> I have developed the attached patch to warn about column reordering in
>> this odd case. The patch mentions the reordering of c:
>
>> NOTICE: merging column "a" with inherited definition
>> NOTICE: merging column "c" with in
> * Isn't "X >> Y" equivalent to "network_scan_first(X) < Y AND
> network_scan_last(X) > Y"? Or at least close enough for selectivity
> estimation purposes? Pardon my ignorance - I'm not too familiar with the
> inet datatype - but how about just calling scalarineqsel for both bounds?
Actually,
> Heikki Linnakangas writes:
> > * inet_mcv_join_selec() is O(n^2) where n is the number of entries in
> > the MCV lists. With the max statistics target of 1, a worst case
> > query on my laptop took about 15 seconds to plan. Maybe that's
> > acceptable, but you went through some trouble to
Simon Riggs writes:
> Suggest discretize() as a much more informative name. The other names
> will be overlooked by anybody that doesn't already know what to look
> for.
I did not like that idea to begin with, but it's growing more attractive.
In particular, I think it would be unique enough that
> What you did there is utterly unacceptable from a modularity standpoint;
> and considering that the values will be nowhere near right, the argument
> that "it's better than returning a constant" seems pretty weak. I think
> you should just take that out again.
I will try to come up with a bette
David G Johnston writes:
> Would it be proper to issue an additional top-level warning with the column
> moved notification? Thus there would be NOTICE, NOTICE, WARNING in the
> above example? Or, more generically, "columns reordered to match inherited
> column order" to avoid multiple warnings
Hi community,
while I am currently investigating why a certain table with highly redundant
and utterly verbose xml becomes worse storage wise when making the xml more
compact. Since i am quite new to this, I believe its the lz compression in the
text database. But thats irrelevant now, just ment
On 01/09/14 06:00, Tom Lane wrote:
Simon Riggs writes:
Suggest discretize() as a much more informative name. The other names
will be overlooked by anybody that doesn't already know what to look
for.
I did not like that idea to begin with, but it's growing more attractive.
In particular, I thin
On 30/08/14 19:24, Tom Lane wrote:
Pavel Stehule writes:
1. I am thinking so reduction to only numeric types is not necessary -
although we can live without it - but there are lot of non numeric
categories: chars, date, ...
I wasn't terribly happy about that either. I still think we should
r
Another thought about this general topic:
Alvaro Herrera writes:
> ...
> Allowed actions on a RELKIND_PARTITION:
> * CREATE INDEX .. ON PARTITION ON TABLE
> ...
> Still To Be Designed
>
> * Are indexes/constraints inherited from the parent rel?
I think one of the key desig
Petr Jelinek writes:
> On 30/08/14 19:24, Tom Lane wrote:
>> I wasn't terribly happy about that either. I still think we should
>> reduce this to a single polymorphic function, as in the attached.
> I did try to write generic function very similar to what you wrote but
> discarded it because of
On 08/31/2014 10:03 PM, Tom Lane wrote:
> Another thought about this general topic:
>
> Alvaro Herrera writes:
>> ...
>> Allowed actions on a RELKIND_PARTITION:
>> * CREATE INDEX .. ON PARTITION ON TABLE
>> ...
>> Still To Be Designed
>>
>> * Are indexes/constraints inherite
On Fri, Aug 29, 2014 at 12:35:50PM -0400, Tom Lane wrote:
> > Each partition is assigned an Expression that receives a tuple and
> > returns boolean. This expression returns true if a given tuple belongs
> > into it, false otherwise.
>
> -1, in fact minus a lot. One of the core problems of the c
On 31 August 2014 20:44, Gavin Flower wrote:
> On 01/09/14 06:00, Tom Lane wrote:
>>
>> Simon Riggs writes:
>>>
>>> Suggest discretize() as a much more informative name. The other names
>>> will be overlooked by anybody that doesn't already know what to look
>>> for.
>>
>> I did not like that ide
On 31/08/14 22:33, Tom Lane wrote:
Petr Jelinek writes:
On 30/08/14 19:24, Tom Lane wrote:
I wasn't terribly happy about that either. I still think we should
reduce this to a single polymorphic function, as in the attached.
I did try to write generic function very similar to what you wrote
Simon Riggs wrote
> width_bucket() seems to refer to an equal-width binning process. The
> function being discussed here is a generic mechanism, the boundaries
> of which could have been decided using equal-frequency or other
> mechanisms. Using the word "width" in those contexts could be
> confusi
Petr Jelinek writes:
> On 31/08/14 22:33, Tom Lane wrote:
>> Petr Jelinek writes:
>>> The difference between my generic and Tom's generic is because Tom's is
>>> slowed down by the deconstruct_array.
>> Meh. It looked to me like your version would have O(N^2) performance
>> problems from comput
David G Johnston writes:
> Since "bucket" is the 'verb' here (in this specific case meaning "lookup the
> supplied value in the supplied bucket definition") and "width" is a modifier
> (the bucket specification describes an equal-width structure) I suggest
> "literal_bucket(val, array[])" such tha
On Sun, Aug 31, 2014 at 7:48 PM, Tom Lane wrote:
> David G Johnston writes:
> > Since "bucket" is the 'verb' here (in this specific case meaning "lookup
> the
> > supplied value in the supplied bucket definition") and "width" is a
> modifier
> > (the bucket specification describes an equal-width
On 08/31/2014 12:40 PM, Dobes Vandermeer wrote:
> 1. Connecting to multiple databases
>
> The background workers can apparently only connect to a single database
> at a time, but I want to expose all the databases via the API.
bgworkers are assigned a database at launch time (if SPI is enabled),
On Sun, Aug 31, 2014 at 10:10 AM, Peter Eisentraut wrote:
>
> On 8/30/14 2:26 AM, Jeff Janes wrote:
> > But there cases were people use COPY in a loop with a small amount of
> > data in each statement.
>
> What would be the reason for doing that?
>
I used that to the same thing many times. In a c
> On 08/29/2014 04:59 AM, Kevin Grittner wrote:
>> I just took a quick look at the spec to refresh my memory, and it
>> seems to require that the WITH TIME ZONE types store UTC (I suppose
>> for fast comparisons), it requires the time zone in the form of a
>> hour:minute offset to be stored with it
Adam, all,
* Brightwell, Adam (adam.brightw...@crunchydatasolutions.com) wrote:
> Attached is a patch for RLS that was create against master at
> 01363beae52700c7425cb2d2452177133dad3e93 and is ready for review.
Many thanks for posting this. As others may realize already, I've
reviewed and modif
On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao wrote:
>
> Hi,
>
> I'd like to propose to add new option "--immediate" to pg_ctl promote.
> When this option is set, recovery ignores any WAL data which have not
> been replayed yet and exits immediately. Patch attached.
>
> This promotion is faster tha
38 matches
Mail list logo
