Hello,
At Wed, 27 Jul 2016 19:53:01 +0800, Craig Ringer wrote
in
> On 25 July 2016 at 22:43, Peter Eisentraut > wrote:
>
> > Example: I have a database cluster initialized with --locale=ru_RU.UTF-8
> > (built with NLS). Let's say for some reason, I have client encoding set
> > to LATIN1. Al
On Sun, Jul 17, 2016 at 02:55:20PM -0400, Jan Wieck wrote:
> On Sun, Jul 17, 2016 at 2:08 PM, Jim Nasby wrote:
> > On 7/13/16 2:06 PM, Joshua D. Drake wrote:
> >> On 07/07/2016 01:01 PM, Robert Haas wrote:
> >> There was an unconference session on this topic at PGCon and quite a
> >>> number of pe
On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund wrote:
> I think the better fix here would acutally be to get rid of a pointer
> based list here, and a) replace the queue with integer offsets ...
Here is a prototype of that idea. It replaces that dlist with a
proclist, a new specialised doubly-li
On Thu, Jul 28, 2016 at 10:22 AM, Craig Ringer wrote:
> It might, actually. One approach for online upgrade is to:
>
> * pg_basebackup the master
> * start the replica and let it catch up
> * create a logical replication slot on the master
> * replace the replication.conf on the basebackup so it s
On 28 July 2016 at 04:35, Bruce Momjian wrote:
> On Fri, Jul 8, 2016 at 12:18:28AM +0100, Simon Riggs wrote:
> > On 7 July 2016 at 21:10, Robert Haas wrote:
> >
> > pg_upgrade does that, kinda. I'd like to have something better, but
> > in the absence of that, I think it's quite wrong
> On 2016/07/27 13:51, Kouhei Kaigai wrote:
> > This output is, at least, not incorrect.
> > This ForeignScan actually scan a relation that consists of two joined
> > tables on the remote side. So, not incorrect, but may not convenient for
> > better understanding by users who don't have deep inter
Hi,
On 2016-07-26 15:13:41 -0400, Robert Haas wrote:
> On Thu, Jul 21, 2016 at 12:06 PM, Robert Haas wrote:
> > On Wed, Jul 20, 2016 at 9:15 PM, Noah Misch wrote:
> >> This PostgreSQL 9.6 open item now needs a permanent owner. Would any other
> >> committer like to take ownership? If this role
Kevin Grittner writes:
> On Wed, Jul 27, 2016 at 1:47 PM, Tom Lane wrote:
>> this would require an initdb because it changes the
>> representation of stored rules for cases like this,
> So pg_upgrade would not work at all for the version this goes into,
No, pg_upgrade wouldn't have a problem.
On Wed, Jul 27, 2016 at 1:47 PM, Tom Lane wrote:
> I looked into the problem reported in bug #14265,
> attached is a proposed patch that fixes this bug
> this would require an initdb because it changes the
> representation of stored rules for cases like this,
So pg_upgrade would not work at al
On 07/26/2016 08:45 PM, Robert Haas wrote:
> That's why I found Josh's restatement useful - I am assuming without
> proof that his restatement is accurate
FWIW, my restatement was based on some other sites rather than Uber.
Including folks who didn't abandon Postgres.
--
--
Josh Berkus
Red H
On Fri, Jul 8, 2016 at 12:18:28AM +0100, Simon Riggs wrote:
> On 7 July 2016 at 21:10, Robert Haas wrote:
>
> pg_upgrade does that, kinda. I'd like to have something better, but
> in the absence of that, I think it's quite wrong to think about
> deprecating it, even if we had logica
Andres Freund wrote:
> Hi,
>
> I've previously mentioned (e.g. [1]) that tuple deforming is a serious
> bottlneck. I've also experimented successfully [2] making
> slot_deform_tuple() faster.
I'm currently messing with making heapam.c be just one possible
implementation of tuple storage, to allow
I looked into the problem reported in bug #14265,
https://www.postgresql.org/message-id/20160727005725.7438.26...@wrigleys.postgresql.org
The core of the problem is a design decision that seems pretty bad in
hindsight: if we have array-subscripting or field-selection decoration
in the target colum
On 2016-07-27 10:04:52 -0400, Robert Haas wrote:
> On Tue, Jul 26, 2016 at 8:43 PM, Andres Freund wrote:
> > As previously mentioned, dynahash isn't particularly fast. In many cases
> > that doesn't particularly matter. But e.g. hash aggregation and bitmap
> > index scans are quite sensitive to ha
Michael Paquier writes:
> On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood wrote:
>> Michael Paquier writes:
>>
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
>> think we only need three for GSSA
On Wed, Jul 27, 2016 at 08:33:52AM -0500, Merlin Moncure wrote:
> > Or in short, this seems like an annoyance, not a time-for-a-new-database
> > kind of problem.
>
> Well, the real annoyance as I understand it is the raw volume of bytes
> of WAL traffic a single update of a field can cause. They
On Tue, Jul 26, 2016 at 6:15 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 7/26/16 6:14 PM, Vik Fearing wrote:
> > As mentioned elsewhere in the thread, you can just do WHERE true to get
> > around it, so why on Earth have it PGC_SUSET?
>
> I'm not sure whether it's supposed
And as always, I didn't re-check a patch before sending it :) Here is a
corrected version without any fprintf's.
--
Best regards,
Aleksander Alekseev
diff --git a/src/backend/access/gin/ginbulk.c b/src/backend/access/gin/ginbulk.c
index d6422ea..eac76c4 100644
--- a/src/backend/access/gin/ginbulk
Robert Haas writes:
> On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote:
>> I suppose that a fix based on putting PG_TRY blocks into all the affected
>> functions might be simple enough that we'd risk back-patching it, but
>> I don't really want to go that way.
> try/catch blocks aren't completely
Hello
While working on some new feature for PostgreSQL (which is still in
development and is irrelevant in this context) I noticed that current
RBTree implementation interface is following:
```
extern void rb_begin_iterate(RBTree *rb, RBOrderControl ctrl);
extern RBNode *rb_iterate(RBTree *rb);
`
On Wed, Jul 27, 2016 at 10:09 AM, Amit Kapila wrote:
> On Wed, Jul 27, 2016 at 6:46 PM, Robert Haas wrote:
>> On Wed, Jul 27, 2016 at 2:20 AM, Amit Kapila wrote:
>>> Okay, that makes sense to me apart from minor issue reported by
>>> Andrew. I think we might want to slightly rephrase the commen
On Fri, Jul 22, 2016 at 7:15 AM, Anton Dignös wrote:
> We would like to contribute to PostgreSQL a solution that supports the query
> processing of "at each time point". The basic idea is to offer two new
> operators, NORMALIZE and ALIGN, whose purpose is to adjust (or split) the
> ranges of tuple
On Wed, Jul 27, 2016 at 6:46 PM, Robert Haas wrote:
> On Wed, Jul 27, 2016 at 2:20 AM, Amit Kapila wrote:
>> Okay, that makes sense to me apart from minor issue reported by
>> Andrew. I think we might want to slightly rephrase the comments on
>> top of copyParamList() which indicates only about
On Tue, Jul 26, 2016 at 8:43 PM, Andres Freund wrote:
> As previously mentioned, dynahash isn't particularly fast. In many cases
> that doesn't particularly matter. But e.g. hash aggregation and bitmap
> index scans are quite sensitive to hash performance.
>
> The biggest problems with dynahash (a
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yeah. I'm not very impressed by the underlying assumption that it's
>> okay for client-side code to hard-wire knowledge about what indoption
>> bits mean, but not okay for it to hard-wire knowledge about which index
>> AMs use whic
On Tue, Jul 26, 2016 at 5:07 PM, Tom Lane wrote:
> Josh Berkus writes:
>> To explain this in concrete terms, which the blog post does not:
>
>> 1. Create a small table, but one with enough rows that indexes make
>> sense (say 50,000 rows).
>
>> 2. Make this table used in JOINs all over your datab
On Wed, Jul 27, 2016 at 2:20 AM, Amit Kapila wrote:
> Okay, that makes sense to me apart from minor issue reported by
> Andrew. I think we might want to slightly rephrase the comments on
> top of copyParamList() which indicates only about dynamic parameter
> hooks.
I don't see why it needs to be
On Wed, Jul 27, 2016 at 12:25 AM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
> Robert> So I think we instead ought to fix it as in the attached.
>
> Robert>if (retval->paramMask != NULL &&
> Robert> - !bms_is_member(i, retval->paramMask))
>
On 27/07/16 06:11, David Fetter wrote:
> On Wed, Jul 27, 2016 at 03:24:28AM +0200, Vik Fearing wrote:
>> On 27/07/16 03:15, Peter Eisentraut wrote:
>>> On 7/26/16 6:14 PM, Vik Fearing wrote:
As mentioned elsewhere in the thread, you can just do WHERE true
to get around it, so why on Earth
On Tue, Jul 26, 2016 at 9:44 PM, Michael Paquier
wrote:
> On Wed, Jul 27, 2016 at 12:41 AM, John Harvey
> wrote:
> > Because of this, I've submitted a small patch which fixes the verbosity
> of
> > the error message to actually explain what's missing. I hope that this
> > patch will be consider
On 27/07/16 05:45, Robert Haas wrote:
> On Tue, Jul 26, 2016 at 8:27 PM, Stephen Frost wrote:
>> * Joshua D. Drake (j...@commandprompt.com) wrote:
>>> Hello,
>>>
>>> The following article is a very good look at some of our limitations
>>> and highlights some of the pains many of us have been worki
Andrew Borodin writes:
>> I don't think there is any reason for this new code to assume NBASE=1
> There is a comment on line 64 stating that value 1 is hardcoded
> somewhere else, any other value is not recommended and a bunch of code
> is left for historical reasons.
Doesn't matter: ple
On 25 July 2016 at 22:43, Peter Eisentraut wrote:
> Example: I have a database cluster initialized with --locale=ru_RU.UTF-8
> (built with NLS). Let's say for some reason, I have client encoding set
> to LATIN1. All error messages come back like this:
>
> test=> select * from notthere;
> ERROR:
On 27 July 2016 at 10:17, Andrew Borodin wrote:
>> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX
> / NBASE for any NBASE > 1
Interesting. I think it's clearer the way it is in mul_var() though,
because the
On 27 July 2016 at 09:57, Dean Rasheed wrote:
> it could be
> coded using something like
>
> accum->maxdig += NBASE - 1;
> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Propagate carries...
>
Oops, that's not quite right because maxdig is actually epresents the
> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX
/ NBASE for any NBASE > 1
>I don't think there is any reason for this new code to assume NBASE=1
There is a comment on line 64 stating that value 1 is har
On 2016/07/27 13:51, Kouhei Kaigai wrote:
This output is, at least, not incorrect.
This ForeignScan actually scan a relation that consists of two joined
tables on the remote side. So, not incorrect, but may not convenient for
better understanding by users who don't have deep internal knowledge.
On 27 July 2016 at 07:33, Andrew Borodin wrote:
>>I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
>
> I feel that I have to elaborate a bit. Probably my calculations are wrong.
>
> Lets assume we already have accumulated INT_MAX of digits in
> previous-place accum
On 2016/07/27 13:09, Ashutosh Bapat wrote:
The patch always prints ForeignJoin when scanrelid <= 0, which would be
odd considering that FDWs can now push down post-join operations. We
need to device a better way to convey post-join operations. May be
something like
Foreign Grouping, aggregation o
39 matches
Mail list logo
