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
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: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.
> 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 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
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 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:
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 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
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 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 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 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 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
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 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
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 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 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
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);
`
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
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
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
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
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 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
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
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
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
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 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
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.
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
> 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
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 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 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 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
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
39 matches
Mail list logo
