On Fri, Feb 6, 2015 at 2:13 PM, Robert Haas wrote:
> My first comment here is that I think we should actually teach
> heapam.c about parallelism.
I coded this up; see attached. I'm also attaching an updated version
of the parallel count code revised to use this API. It's now called
"parallel_co
On Fri, Feb 6, 2015 at 4:02 PM, Jeff Janes wrote:
> I liked to add comments which would point out some fact that was important
> to testing but which was non-obvious. Often this fact was mentioned
> somewhere in the 300 message thread, but it needs to be called out
> specifically for people intere
On Fri, Feb 6, 2015 at 5:20 AM, Robert Haas wrote:
> On Fri, Feb 6, 2015 at 5:51 AM, Magnus Hagander
> wrote:
> > So in an attempt to actually move this forward in a constructive way I'm
> > going to ignore a bunch of what happened after this email, and fork the
> > discussion at this point.
>
On Wed, Feb 4, 2015 at 04:49:46PM -0800, Peter Geoghegan wrote:
> On Tue, Feb 2, 2015 at 01:06 AM, Andres Freund wrote:
> > A first (not actually that quick :() look through the patches to see
> > what actually happened in the last months. I didn't keep up with the
> > thread.
>
> So, let me get
On Fri, Feb 6, 2015 at 2:13 PM, Robert Haas wrote:
> The complicated part here seems to me to figure out what we need to
> pass from the parallel leader to the parallel worker to create enough
> state for quals and projection. If we want to be able to call
> ExecScan() without modification, which
On Thu, Feb 5, 2015 at 10:28 AM, Amit Kapila wrote:
> Currently in pg_stat_statements, the setup to track
> instrumentation/totaltime information is done after
> ExecutorStart(). Can we do this before ExecutorStart()?
> In particular, I am referring to below code:
>
> static void
> pgss_ExecutorS
On Fri, Feb 6, 2015 at 12:34 PM, Robert Haas wrote:
> 4.
Obviously that went out a bit too soon. Anyway, what I think we
should do here is back up a bit and talk about what the problems are
that we need to solve here and how each of them should be solved. I
think there is some good code in this
On Fri, Feb 6, 2015 at 9:43 AM, Amit Kapila wrote:
> Here is the latest patch which fixes reported issues and supported
> Prepared Statements and Explain Statement for parallel sequential
> scan.
>
> The main purpose is to get the feedback if possible on overall
> structure/design of code before I
Etsuro Fujita writes:
> On 2015/02/03 15:32, Ashutosh Bapat wrote:
>> Instead, can we show all the relations that are being modified e.g
>> Update on child1, child2, child3. That will disambiguate everything.
> That's an idea, but my concern about that is the cases where there are a
> large numb
On Fri, Feb 6, 2015 at 6:35 PM, Syed, Rahila wrote:
> The compression patch can use the latest interface
> MemoryContextAllocExtended to proceed without compression when sufficient
> memory is not available for
> scratch buffer.
> The attached patch introduces OutOfMem flag which is set on when
Amit Langote writes:
> I wonder why I cannot find a way to get a range type for a given (sub-)
> type. I would like to build a RangeType from Datum's of lower and upper
> bounds. Much like how construct_array() builds an ArrayType from a Datum
> array of elements given elements' type info.
> Is t
On 29 January 2015 at 23:38, Peter Geoghegan wrote:
> On Sat, Jan 17, 2015 at 6:48 PM, Peter Geoghegan wrote:
> > I continued with this since posting V2.0.
>
> Attached version (V2.1) fixes bit-rot caused by the recent changes by
> Stephen ("Fix column-privilege leak in error-message paths"). Mo
On Thu, Jan 22, 2015 at 10:30 AM, Amit Kapila
wrote:
>
> On Thu, Jan 22, 2015 at 6:37 AM, Kouhei Kaigai
wrote:
> >
> > (Please point out me if my understanding is incorrect.)
> >
> > What happen if dynamic background worker process tries to reference
temporary
> > tables? Because buffer of tempor
>In any case, those things have been introduced by what I did in previous
>versions... And attached is a new patch.
Thank you for feedback.
> /* allocate scratch buffer used for compression of block images */
>+ if (compression_scratch == NULL)
>+ compression_scratch = Me
Hi David and others!
David Fetter writes:
> On Tue, Jan 27, 2015 at 08:02:37AM +0100, Daniel Bausch wrote:
>>
>> Tom Lane writes:
>>
>> >> Wait for first IO, issue second IO request
>> >> Compute
>> >> Already have second IO request, issue third
>> >> ...
>> >
>> >> We'd be a lot less sensiti
On 02/05/2015 02:15 PM, Jan Wieck wrote:
On 02/05/2015 01:18 PM, Marko Tiikkaja wrote:
"pgcrypto bug"
That doesn't look too good, but I can't reproduce it against 9.3.6 either.
Attached is an improved script and the final output from it. I ran it
over night and it did not reproduce
On Thu, Feb 5, 2015 at 10:21 PM, Ian Barwick wrote:
> I stumbled on what appears to be inconsistent handling of double slashes
> in tablespace paths when using pg_basebackup with the -T/--tablespace-mapping
> option:
>
> ibarwick:postgresql (master)$ mkdir /tmp//foo-old
[...]
> The attached pa
On Fri, Feb 6, 2015 at 5:51 AM, Magnus Hagander wrote:
> So in an attempt to actually move this forward in a constructive way I'm
> going to ignore a bunch of what happened after this email, and fork the
> discussion at this point.
Thanks, and I probably owe you an apology for some of that, so,
On Fri, Feb 6, 2015 at 5:55 AM, Magnus Hagander wrote:
> On Mon, Jan 26, 2015 at 10:29 PM, Robert Haas wrote:
>> (While I'm complaining, the links only go to the "flat" version of the
>> thread, while I happen to prefer the version that shows one message at
>> a time with a message-ID selector to
On Fri, Feb 6, 2015 at 1:23 PM, Michael Paquier
wrote:
> On Thu, Feb 5, 2015 at 11:58 PM, Michael Paquier wrote:
>> An updated patch is attached.
> I just noticed that the patch I sent was incorrect:
> - Parameter name was still wal_availability_check_interval and not
> wal_retrieve_retry_interval
On Fri, Feb 6, 2015 at 4:30 PM, Michael Paquier wrote:
> On Fri, Feb 6, 2015 at 3:03 PM, Fujii Masao wrote:
>> Do we always need extra two bytes for compressed backup block?
>> ISTM that extra bytes are not necessary when the hole length is zero.
>> In this case the length of the original backup bl
On Fri, Feb 6, 2015 at 3:03 PM, Fujii Masao wrote:
> Do we always need extra two bytes for compressed backup block?
> ISTM that extra bytes are not necessary when the hole length is zero.
> In this case the length of the original backup block (i.e., uncompressed)
> must be BLCKSZ, so we don't need
On 2015-02-06 11:51:50 +0100, Magnus Hagander wrote:
> So in an attempt to actually move this forward in a constructive way I'm
> going to ignore a bunch of what happened after this email, and fork the
> discussion at this point.
Sounds good.
> First of all - assuming we'lI fix this particular t
On Fri, Feb 6, 2015 at 3:22 PM, Kyotaro HORIGUCHI
wrote:
> Sorry, I misunderstood that.
>
>> > At Wed, 4 Feb 2015 19:22:39 +0900, Fujii Masao
>> > wrote in
>> >
>> >> On Wed, Feb 4, 2015 at 4:58 PM, Kyotaro HORIGUCHI
>> >> wrote:
>> >> > I'm very sorry for confused report. The problem found i
On Fri, Feb 6, 2015 at 4:15 AM, Michael Paquier
wrote:
> On Thu, Feb 5, 2015 at 11:06 PM, Syed, Rahila wrote:
>>>/*
>>>+* We recheck the actual size even if pglz_compress() report success,
>>>+* because it might be satisfied with having saved as little as one byte
>>>+* in the compres
On Mon, Jan 26, 2015 at 10:16 PM, Robert Haas wrote:
> On Mon, Jan 26, 2015 at 4:07 PM, Magnus Hagander
> wrote:
> > I assume what was referred to was that the old cf app would show the
> last 3
> > (I think it was) comments/patches/whatnot on a patch on the summary page
> > (and then clickthrou
On Mon, Jan 26, 2015 at 10:29 PM, Robert Haas wrote:
> (While I'm complaining, the links only go to the "flat" version of the
> thread, while I happen to prefer the version that shows one message at
> a time with a message-ID selector to switch messages.)
>
Then you're clicking the wrong link :)
On Mon, Jan 26, 2015 at 9:46 PM, Robert Haas wrote:
> On Mon, Jan 26, 2015 at 3:24 PM, Magnus Hagander
> wrote:
> > Yes, and the agreement after that feedback was to try it out and then
> figure
> > out what changes were needed? As about half the feedback said it was
> better
> > without and hal
On Fri, Feb 6, 2015 at 1:46 PM, Heikki Linnakangas wrote:
> It simplifies the code to do all the sleeping and interrupt handling code in
> the upper level, in secure_[read|write]. Do you see a problem with it?
Not directly. Reading the code I got uneasy with the fact that we fact
unconditionally th
On 2015-02-05 16:45:50 +0200, Heikki Linnakangas wrote:
> Looking again at the code after Andres' interrupt-handling patch series, I
> got confused by the fact that there are several wait-retry loops in
> different layers, and reading and writing works slightly differently.
They don't really work
On 02/06/2015 10:38 AM, Michael Paquier wrote:
On Thu, Feb 5, 2015 at 6:45 PM, Heikki Linnakangas wrote:
Looking again at the code after Andres' interrupt-handling patch series, I
got confused by the fact that there are several wait-retry loops in
different layers, and reading and writing works
On 02/06/2015 08:16 AM, Michael Paquier wrote:
On Fri, Jan 30, 2015 at 10:26 PM, Andreas Karlsson wrote:
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Looking at the latest patch, it seems that in
AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
AT_AddConstraintRecurse an
Well let's see what others think. Also, we might want to separate that
information on result relations heading probably.
On Fri, Feb 6, 2015 at 1:35 PM, Etsuro Fujita
wrote:
> Hi Ashutosh,
>
> Thank you for the review!
>
>
> On 2015/02/03 15:32, Ashutosh Bapat wrote:
>
>> I agree that it's a pro
On Thu, Feb 5, 2015 at 6:45 PM, Heikki Linnakangas wrote:
> Looking again at the code after Andres' interrupt-handling patch series, I
> got confused by the fact that there are several wait-retry loops in
> different layers, and reading and writing works slightly differently.
>
> I propose the atta
Hi Ashutosh,
On 2015/02/03 16:44, Ashutosh Bapat wrote:
I am having some minor problems running this repro
[Terminal 2]
postgres=# create foreign table ft (a int) server loopback options
(table_name 'lbt');
There isn't any table "lbt" mentioned here. Do you mean "t" here?
Sor
Hello,
> Redshift has a table, stv_inflight, which serves about the same purpose as
> pg_stat_activity. Redshift seems to perform better with very high fetch
> sizes (10,000 is a good start), so the default foreign data wrapper didn't
> perform so well.
I agree with you.
> I was able to confirm
Hi Ashutosh,
Thank you for the review!
On 2015/02/03 15:32, Ashutosh Bapat wrote:
I agree that it's a problem, and it looks more severe when there are
multiple children
postgres=# create table parent (a int check (a < 0) no inherit);
CREATE TABLE
postgres=# create table child1 (a int check (a >
37 matches
Mail list logo
