On 2015/12/09 2:56, Robert Haas wrote:
On Thu, Dec 3, 2015 at 9:51 PM, Noah Misch wrote:
On Tue, Dec 01, 2015 at 11:05:47AM -0500, Robert Haas wrote:
On Mon, Nov 30, 2015 at 2:43 PM, Tom Lane wrote:
* Foreign join pushdown vs EvalPlanQual
Is this fixed by 5fc4c26db? If not, what remains to
Robert Haas writes:
> With respect to this particular thing, it's hard for me to imagine
> that anything will go wrong on ppcle that we wouldn't consider a
> back-patchable fix, so there might be no harm in adjusting
> config.guess and config.sub.
FWIW, I also suspect that supporting ppc64le woul
On 2015-12-09 16:30:47 +0900, Michael Paquier wrote:
> > I'm kinda wondering if it wouldn't have been better to go through shared
> > buffers in ResetUnloggedRelationsInDbspaceDir() instead of using
> > copy_file().
>
> For deployment with large shared_buffers settings, wouldn't that be
> actually
On Tue, Dec 8, 2015 at 9:57 PM, Andres Freund wrote:
> For me the attached, preliminary, patch, fixes the problem in master;
> previous branches ought to look mostly similar, except the flush moved
> to RestoreBackupBlockContents/RestoreBackupBlock.
> Does anybody have a better idea? Suitable for
Hi Tom
With --build=powerpc64le-unknown-linux-gnu in the config_opts section
of build-farm.conf,
the build and the regression were successful.
Well, by the time the decision is made on this, I have enabled only 9.4+
runs on ppc64le. The results from this buildfarm member 'clam' are now
being repo
On 2015/12/09 11:19, Amit Langote wrote:
> On 2015/12/09 5:50, Robert Haas wrote:
>> I suspect this is an oversight. We allowed FOREIGN KEY constraints to
>> be not valid in 722bf7017bbe796decc79c1fde03e7a83dae9ada by Simon
>> Riggs, but didn't add allow it for CHECK constraints until Alvaro's
>>
On Tue, Dec 8, 2015 at 10:09 PM, Andres Freund wrote:
> On 2015-12-04 21:57:54 +0900, Michael Paquier wrote:
>> On Fri, Dec 4, 2015 at 5:10 PM, Andres Freund wrote:
>> >> Let's go for XLOG_FPI_FLUSH.
>> >
>> > I think the other way is a bit better, because we can add new flags
>> > without changi
Hello,
At Tue, 8 Dec 2015 20:50:39 +0900, Michael Paquier
wrote in
> On Tue, Dec 8, 2015 at 6:31 PM, Kyotaro HORIGUCHI
> wrote:
> > >
> >
> > I believe I haven't ripped off any in CC: list or In-Reply-To and
> > References in the previous post. (I read "top-post" as a post
> > without these h
On Wed, Dec 9, 2015 at 6:48 AM, Haribabu Kommi
wrote:
>
> On Wed, Dec 9, 2015 at 2:36 AM, Amit Kapila
wrote:
> >
> > I think it is better to have check on number of args in the
> > above functions similar to what we have in ginarrayextract_2args.
>
> ginarrayextract_2args is an deprecated functio
Could we get this rebased past the merge of the parallel execution commits?
Thanks,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-12-09 6:10 GMT+01:00 Michael Paquier :
> On Wed, Dec 9, 2015 at 2:07 PM, Pavel Stehule
> wrote:
> > should be noted, recorded somewhere so this introduce possible
> compatibility
> > issue - due default processing .psqlrc.
>
> That's written in the commit log, so I guess that's fine.
>
ook
On Wed, Dec 9, 2015 at 2:07 PM, Pavel Stehule wrote:
> should be noted, recorded somewhere so this introduce possible compatibility
> issue - due default processing .psqlrc.
That's written in the commit log, so I guess that's fine.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hack
2015-12-09 1:27 GMT+01:00 Michael Paquier :
> On Wed, Dec 9, 2015 at 5:08 AM, Pavel Stehule
> wrote:
> > 2015-12-08 20:09 GMT+01:00 Robert Haas :
> >> On Sun, Dec 6, 2015 at 9:27 AM, Michael Paquier
> >> wrote:
> >> > On Sun, Dec 6, 2015 at 10:56 PM, Michael Paquier
> >> > wrote:
> >> >> Thanks
On Tue, Dec 8, 2015 at 11:12 PM, David Rowley
wrote:
> My point was more of a response to the general condition that we cannot add
> any planner overhead unless the extra CPU cycles spent are almost certainly
> going improve the plan.
I hope that's an overstatement of the requirement, because oth
> On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
> wrote:
> >> I think the actual regression test outputs are fine, and that your
> >> desire to suppress part of the plan tree from showing up in the
> >> EXPLAIN output is misguided. I like it just the way it is. To
> >> prevent user confusion, I
On 9 December 2015 at 15:14, Robert Haas wrote:
> On Mon, Dec 7, 2015 at 8:26 PM, David Rowley
> wrote:
> > The biggest frustration for me is that the way Tom always seems to argue
> his
> > point it's as if planning time is roughly the same or more expensive than
> > execution time, and likely
On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
wrote:
>> I think the actual regression test outputs are fine, and that your
>> desire to suppress part of the plan tree from showing up in the
>> EXPLAIN output is misguided. I like it just the way it is. To
>> prevent user confusion, I think that
On Tue, Dec 8, 2015 at 7:09 PM, Peter Geoghegan wrote:
> Why multiply by BLCKSZ here?
I ask because LogicalTapeSetBlocks() returns blocks directly, not
tapes, and I'd expect the same. Also, the callers seem to expect
blocks, not bytes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing l
On 9 Dec 2015 02:44, "Peter Geoghegan" wrote:
>
> I guess you mean insertion sort. What's the theoretical justification
> for the change?
Er, right. Insertion sort.
The sort networks I used here are optimal both in number of comparisons and
depth. I suspect modern CPUs actually manage to do some
On Tue, Dec 8, 2015 at 6:44 PM, Peter Geoghegan wrote:
> On Tue, Dec 8, 2015 at 6:39 PM, Greg Stark wrote:
>> Fwiw attached are two patches for perusal. One is a trivial patch to
>> add the size of the tape to trace_sort output. I guess I'll just apply
>> that without discussion.
>
> +1
>> +/*
>
On 2015/12/09 1:13, Robert Haas wrote:
On Tue, Dec 8, 2015 at 5:49 AM, Etsuro Fujita
wrote:
I'd like to discuss the next
thing about his patch. As I mentioned in [1], the following change in
the patch will break the EXPLAIN output.
@@ -205,6 +218,11 @@ ExecInitForeignScan(ForeignScan *node, E
On Tue, Dec 8, 2015 at 6:39 PM, Greg Stark wrote:
> Fwiw attached are two patches for perusal. One is a trivial patch to
> add the size of the tape to trace_sort output. I guess I'll just apply
> that without discussion.
+1
> The other replaces the selection sort with an
> open coded sort networ
On Wed, Dec 9, 2015 at 12:02 AM, Jeff Janes wrote:
>
>
> Then in the next (final) merge, it is has to read in this huge
> fragmented tape run emulation, generating a lot of random IO to read
> it.
This seems fairly plausible. Logtape.c is basically implementing a
small filesystem and doesn't real
On Wed, Dec 9, 2015 at 11:23 AM, Robert Haas wrote:
> Boy, that's awful. Whoever designed that bit of wonderfulness should
> have their language design license revoked.
If one would want to work on a check with pidfile, he/she could check
for tell($pidfile) == -1 which corresponds to an undetermi
On Tue, Dec 8, 2015 at 6:09 PM, Michael Paquier
wrote:
> On Wed, Dec 9, 2015 at 4:47 AM, Robert Haas wrote:
>> On Thu, Dec 3, 2015 at 11:28 PM, Michael Paquier
>> wrote:
>> > This does not impact the run, but it creates unwelcome warnings in the
>> > logs. This is actually caused by the followin
On 2015/12/09 5:50, Robert Haas wrote:
> On Thu, Dec 3, 2015 at 3:52 AM, amul sul wrote:
>> Can we pass initially_valid instead of !skip_validation to StoreRelCheck()
>> in AddRelationNewConstraints(), as shown below?
>
> The comments say this:
>
> * If skip_validation is true then we skip che
On Fri, Dec 4, 2015 at 12:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Still, maybe we should try to sneak at least this much into
>> 9.5 RSN, because I have to think this is going to help people with
>> mostly-NULL (or mostly-really-wide) columns.
>
> Please no. We are trying to get to relea
On Mon, Dec 7, 2015 at 8:26 PM, David Rowley
wrote:
> The biggest frustration for me is that the way Tom always seems to argue his
> point it's as if planning time is roughly the same or more expensive than
> execution time, and likely that's true in many cases, but I would imagine in
> more norma
On Wed, Dec 9, 2015 at 2:36 AM, Amit Kapila wrote:
>
> Few assorted comments:
Thanks for the review.
> 1.
> + /*
> + * SQL-accessible SRF to return all the settings from the pg_hba.conf
> + * file.
> + */
> + Datum
> + pg_hba_lookup_2args(PG_FUNCTION_ARGS)
> + {
> + return pg_hba_lookup(fcinfo);
Hi all,
Thank you for all of your responses.
Meanwhile, I will repost this at pgsql-gene...@postgresql.org
Regards,
Fattah
On 09/12/2015, David G. Johnston wrote:
> On Tue, Dec 8, 2015 at 4:43 PM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Tue, Dec 8, 2015 at 3:33 AM, Fat
On Wed, Dec 9, 2015 at 5:08 AM, Pavel Stehule wrote:
> 2015-12-08 20:09 GMT+01:00 Robert Haas :
>> On Sun, Dec 6, 2015 at 9:27 AM, Michael Paquier
>> wrote:
>> > On Sun, Dec 6, 2015 at 10:56 PM, Michael Paquier
>> > wrote:
>> >> Thanks, I looked at that again and problem is fixed as attached.
>>
On Wed, Dec 9, 2015 at 8:57 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>
>> This code should have checked for the return result of open instead of
>> looking at $pidfile. This has been noticed by Noah as well afterwards
>> and already addressed as 9821492.
>
> Oops, sorry I didn't credit y
On Tue, Dec 8, 2015 at 12:36 PM, Robert Haas wrote:
> On Wed, Dec 2, 2015 at 5:24 PM, Tom Lane wrote:
> > Jeff Janes writes:
> >> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote:
> >>> If you're fixing the dashed-line code, is there a way to say that we
> >>> never have more than a reasonab
On Mon, Dec 7, 2015 at 9:01 AM, Jeff Janes wrote:
>
> The patched one ends with a 2-way, two sequential 233-way merges, and
> a final 233-way merge:
>
> LOG: finished 2-way merge step: CPU 62.08s/435.70u sec elapsed 587.52 sec
> LOG: finished 233-way merge step: CPU 77.94s/660.11u sec elapsed 89
On 12/8/15 3:52 AM, Jeremy Harris wrote:
On 07/12/15 16:44, Simon Riggs wrote:
There are many optimizations we might adopt, yet planning time is a factor.
It seems simple enough to ignore more complex optimizations if we have
already achieved a threshold cost (say 10). Such a test would add near
Michael Paquier wrote:
> This code should have checked for the return result of open instead of
> looking at $pidfile. This has been noticed by Noah as well afterwards
> and already addressed as 9821492.
Oops, sorry I didn't credit you in the commit message.
--
Álvaro Herrerahtt
On 12/7/15 7:26 PM, David Rowley wrote:
I was talking to Thomas Munro yesterday about this, and he mentioned
that it would be quite nice to have some stats on how much time is spent
in the planner, vs executor. He came up with the idea of adding a column
to pg_stat_statements to record the planni
On Tue, Dec 8, 2015 at 4:43 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Dec 8, 2015 at 3:33 AM, FattahRozzaq wrote:
>
>> Hi all,
>>
>> Please help...
>>
>> I have 1 master PostgreSQL and 1 standby PostgreSQL.
>> Both servers has the same OS Linux Debian Wheezy, the same h
On Sun, Dec 6, 2015 at 7:30 PM, Jim Nasby wrote:
> On 9/14/15 7:24 AM, Jan Wieck wrote:
>> On 09/12/2015 11:35 AM, Kevin Grittner wrote:
>>
>>> On the other hand, a grep indicates that there are two places that
>>> MemoryContextData.nextchild is set (and we therefore probably need
>>> to also set
On Tue, Dec 8, 2015 at 3:33 AM, FattahRozzaq wrote:
> Hi all,
>
> Please help...
>
> I have 1 master PostgreSQL and 1 standby PostgreSQL.
> Both servers has the same OS Linux Debian Wheezy, the same hardware.
>
> Both server hardware:
> CPU: 24 cores
> RAM: 128GB
> Disk-1: 800GB SAS (for OS, logs
On Tue, Dec 8, 2015 at 7:33 PM, FattahRozzaq wrote:
> The WAL archive is at /home/postgres/archive/master/, right?
> This directory consume more than 750GB of Disk-1.
> Each segment in the /home/postgres/archive/master/ is 16MB each
> There are currently 47443 files in this folder.
>
> I want to l
On 7 December 2015 at 01:30, Jim Nasby wrote:
> On 9/14/15 7:24 AM, Jan Wieck wrote:
>>
>> On 09/12/2015 11:35 AM, Kevin Grittner wrote:
>>
>>> On the other hand, a grep indicates that there are two places that
>>> MemoryContextData.nextchild is set (and we therefore probably need
>>> to also set
On 12/8/15 1:36 PM, Robert Haas wrote:
Your point is also valid, so I don't mean to detract from that. But
the status quo is definitely annoying.
+1, and I even use -S.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data i
Hi all,
Please help...
I have 1 master PostgreSQL and 1 standby PostgreSQL.
Both servers has the same OS Linux Debian Wheezy, the same hardware.
Both server hardware:
CPU: 24 cores
RAM: 128GB
Disk-1: 800GB SAS (for OS, logs, WAL archive directory)
Disk-2: 330GB SSD (for PostgreSQL data directory
I have downloaded a fresh copy of the Win x64 installer
(postgresql-9.4.5-2-windows-x64.exe) from
http://www.enterprisedb.com/products-services-training/pgdownload. The output
of pg_config and assodicated directory listing of include/server:
BINDIR = C:/PROGRA~1/POSTGR~1/9.4/bin
DOCDIR = C:/PRO
On Wed, Dec 9, 2015 at 4:47 AM, Robert Haas wrote:
>
> On Thu, Dec 3, 2015 at 11:28 PM, Michael Paquier
> wrote:
> > This does not impact the run, but it creates unwelcome warnings in the
> > logs. This is actually caused by the following code in PostgresNode
> > that uses an incorrect check to s
On Fri, Dec 4, 2015 at 7:15 AM, Aleksander Alekseev
wrote:
> Current implementation of ResourceOwner uses arrays to store resources
> like TupleDescs, Snapshots, etc. When we want to release one of these
> resources ResourceOwner finds it with linear scan. Granted, resource
> array are usually sma
On 12/8/15 1:06 PM, Robert Haas wrote:
> I don't really want to get into an argument about this, but is the
> reason we haven't updated config.guess and config.sub in the past that
> it presents an actual stability risk, or just that nobody's asked
> before? Because the first one is a good reason
On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
> I wrote:
>> Merlin Moncure writes:
>>> The following patch deals with a long standing gripe of mine that the
>>> terminal frequently gets garbled so that when typing.
>
>> Hm. I wonder whether rl_resize_terminal() exists in every iteration
>> of
On Tue, Dec 8, 2015 at 12:31 PM, Tom Lane wrote:
> For grins I tried running the TAP tests on my ancient HPUX box that
> hosts pademelon and gaur. At first they showed a lot of failures,
> which I eventually determined were happening because slurp_file was
> only retrieving part of the postmaster
On Thu, Dec 3, 2015 at 3:52 AM, amul sul wrote:
> Hi ALL,
>
> Need your suggestions.
> initially_valid flag is added to make column constraint valid. (commit :
> http://www.postgresql.org/message-id/e1q2ak9-0006hk...@gemulon.postgresql.org)
>
>
> IFAICU, initially_valid and skip_validation values
On Tue, Dec 8, 2015 at 2:33 PM, Merlin Moncure wrote:
> On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
>> I wrote:
>>> Merlin Moncure writes:
The following patch deals with a long standing gripe of mine that the
terminal frequently gets garbled so that when typing.
>>
>>> Hm. I wonde
On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane wrote:
> I wrote:
>> Merlin Moncure writes:
>>> The following patch deals with a long standing gripe of mine that the
>>> terminal frequently gets garbled so that when typing.
>
>> Hm. I wonder whether rl_resize_terminal() exists in every iteration
>> of
2015-12-08 20:09 GMT+01:00 Robert Haas :
> On Sun, Dec 6, 2015 at 9:27 AM, Michael Paquier
> wrote:
> > On Sun, Dec 6, 2015 at 10:56 PM, Michael Paquier
> > wrote:
> >> Thanks, I looked at that again and problem is fixed as attached.
> >
> > Er, not exactly... poll_query_until in PostgresNode.pm
I wrote:
> Merlin Moncure writes:
>> The following patch deals with a long standing gripe of mine that the
>> terminal frequently gets garbled so that when typing.
> Hm. I wonder whether rl_resize_terminal() exists in every iteration
> of libreadline and libedit.
Quick followup: rl_resize_termi
On Thu, Dec 3, 2015 at 11:28 PM, Michael Paquier
wrote:
> This does not impact the run, but it creates unwelcome warnings in the
> logs. This is actually caused by the following code in PostgresNode
> that uses an incorrect check to see if the file has been correctly
> opened or not:
> open my
On Thu, Dec 3, 2015 at 2:27 AM, Vladimir Sitnikov
wrote:
> I've recently noticed W-TinyLfu cache admission policy (see [1]) being
> used for caffeine "high performance caching library for Java 8".
> It demonstrates high cache hit ratios (see [2]) and enables to build
> high-throughput caches (see
On Wed, Dec 2, 2015 at 5:24 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote:
>>> If you're fixing the dashed-line code, is there a way to say that we
>>> never have more than a reasonable number of dashes (ideally, the width
>>> of the terminal) no
On Thu, Dec 3, 2015 at 1:48 AM, Amit Kapila wrote:
> I think the way to address is don't add backend to Group list if it is
> not intended to update the same page as Group leader. For transactions
> to be on different pages, they have to be 32768 transactionid's far apart
> and I don't see much p
On Tue, Dec 8, 2015 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> I don't really want to get into an argument about this, but is the
>> reason we haven't updated config.guess and config.sub in the past that
>> it presents an actual stability risk, or just that nobody's asked
>> before? Be
Merlin Moncure writes:
> The following patch deals with a long standing gripe of mine that the
> terminal frequently gets garbled so that when typing.
Hm. I wonder whether rl_resize_terminal() exists in every iteration
of libreadline and libedit.
regards, tom lane
--
On Tue, Dec 08, 2015 at 01:51:57PM -0500, Robert Haas wrote:
> On Fri, Dec 4, 2015 at 11:08 AM, Catalin Iacob wrote:
> > On Fri, Dec 4, 2015 at 3:47 PM, Robert Haas wrote:
> >> For the most part, the cleanups in this version are just cosmetic: I
> >> fixed some whitespace damage, and reverted som
On Sun, Dec 6, 2015 at 9:27 AM, Michael Paquier
wrote:
> On Sun, Dec 6, 2015 at 10:56 PM, Michael Paquier
> wrote:
>> Thanks, I looked at that again and problem is fixed as attached.
>
> Er, not exactly... poll_query_until in PostgresNode.pm is using psql
> -c without the --no-psqlrc switch so th
On Fri, Dec 4, 2015 at 11:08 AM, Catalin Iacob wrote:
> On Fri, Dec 4, 2015 at 3:47 PM, Robert Haas wrote:
>> For the most part, the cleanups in this version are just cosmetic: I
>> fixed some whitespace damage, and reverted some needless changes to
>> the psql references page that were whitespac
On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia wrote:
> Thanks Ashutosh.
>
> Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
> looks good to me.
This patch needs a rebase.
It's not going to work to say this is a patch proposed for commit when
it's still got a TODO comment in it th
2015-12-05 8:59 GMT+01:00 Pavel Stehule :
>
>
> 2015-11-30 16:34 GMT+01:00 Daniel Verite :
>
>> Pavel Stehule wrote:
>>
>> > [ \rotate being a wrong name ]
>>
>> Here's an updated patch.
>>
>
> Today I have a time to play with it. I am sorry for delay.
>
>
>>
>> First it renames the comman
Robert Haas writes:
> I don't really want to get into an argument about this, but is the
> reason we haven't updated config.guess and config.sub in the past that
> it presents an actual stability risk, or just that nobody's asked
> before? Because the first one is a good reason not to do it now,
On Tue, Dec 8, 2015 at 12:24 PM, Andrew Dunstan wrote:
>>> So, config.guess should be changed to include the build type for ppc64le
>>> like it is in 9.4+ branches.
>>
>> So far as I can tell from a quick troll of the git history, we have never
>> ever updated config.guess/config.sub in released b
Hello,
The following patch deals with a long standing gripe of mine that the
terminal frequently gets garbled so that when typing. I guess this
problem is entirely dependent on pager settings and your interaction
patterns with the window (in particular, if you tend to resize the
window when the p
On Tue, Dec 8, 2015 at 6:43 AM, Andres Freund wrote:
> On 2015-12-04 21:55:29 -0500, Noah Misch wrote:
>> On Thu, Dec 03, 2015 at 07:03:21PM +0100, Andres Freund wrote:
>> > Sorry, but I really just want to see these changes as iterative patches
>> > ontop of 9.5/HEAD instead of this process. I wo
On Thu, Dec 3, 2015 at 9:51 PM, Noah Misch wrote:
> On Tue, Dec 01, 2015 at 11:05:47AM -0500, Robert Haas wrote:
>> On Mon, Nov 30, 2015 at 2:43 PM, Tom Lane wrote:
>> > * Foreign join pushdown vs EvalPlanQual
>> >
>> > Is this fixed by 5fc4c26db? If not, what remains to do?
>>
>> Unfortunately,
"Daniel Verite" writes:
> I notice that --log-file also reports an error but continues nonetheless
> if the file can't be opened.
> The attached trivial patch makes it fail and exit instead.
I agree with doing that.
> Also there's the fact that once opened, psql currently ignores errors
> when w
Hi,
On Wed, Apr 29, 2015, at 01:36 AM, Heikki Linnakangas wrote:
> The problem seems to be that when the standby is promoted, it's a
> so-called "fast promotion", where it writes an end-of-recovery record
> and starts accepting queries before creating a real checkpoint.
> pg_rewind looks at the
For grins I tried running the TAP tests on my ancient HPUX box that
hosts pademelon and gaur. At first they showed a lot of failures,
which I eventually determined were happening because slurp_file was
only retrieving part of the postmaster logfile, causing issues_sql_like
to mistakenly report a f
On 12/08/2015 10:27 AM, Tom Lane wrote:
Sandeep Thakkar writes:
So, config.guess should be changed to include the build type for ppc64le
like it is in 9.4+ branches.
So far as I can tell from a quick troll of the git history, we have never
ever updated config.guess/config.sub in released bra
On Thu, Dec 3, 2015 at 12:01 AM, David Rowley
wrote:
> On 27 July 2015 at 04:58, Heikki Linnakangas wrote:
>> This patch seems sane to me, as far as it goes. However, there's no
>> planner or executor code to use the aggregate combining for anything. I'm
>> not a big fan of dead code, I'd really
Andreas Seltenreich writes:
>> I no longer see "failed to build any n-way joins" after pulling, but
>> there are still instances of "could not devise a query plan". Samples below.
> sorry, I spoke too soon: nine of the former have been logged through the
> night. I'm attaching a larger set of sa
On Wed, Dec 2, 2015 at 8:42 PM, Bruce Momjian wrote:
> No one mentioned the random page docs so I will quote it here:
>
>
> http://www.postgresql.org/docs/9.5/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
>
> Random access to mechanical disk storage is normally m
On Tue, Dec 8, 2015 at 5:49 AM, Etsuro Fujita
wrote:
> On 2015/12/08 3:06, Tom Lane wrote:
>> Robert Haas writes:
>>> I think the core system likely needs visibility into where paths and
>>> plans are present in node trees, and putting them somewhere inside
>>> fdw_private would be going in the o
Hi,
Following last week's commit 344cdff :
Author: Tom Lane
Date: Thu Dec 3 14:28:58 2015 -0500
Clean up some psql issues around handling of the query output file.
Formerly, if "psql -o foo" failed to open the output file "foo", it would
print an error message but then carry on
On Mon, Nov 30, 2015 at 7:47 AM, Kyotaro HORIGUCHI
wrote:
> "Asynchronous execution" is a feature to start substantial work
> of nodes before doing Exec*. This can reduce total startup time
> by folding startup time of multiple execution nodes. Especially
> effective for the combination of joins o
On Tue, Dec 8, 2015 at 9:41 AM, Haribabu Kommi
wrote:
>
> On Sat, Dec 5, 2015 at 3:31 AM, Alvaro Herrera
wrote:
> > Haribabu Kommi wrote:
> >
> >> How about as follows?
> >>
> >> postgres=# select * from pg_hba_lookup('all','all','::1');
> >> line_number | type | database | user | address
Sandeep Thakkar writes:
> So, config.guess should be changed to include the build type for ppc64le
> like it is in 9.4+ branches.
So far as I can tell from a quick troll of the git history, we have never
ever updated config.guess/config.sub in released branches. I'm a bit
hesitant to do it in th
On Tue, Dec 8, 2015 at 3:56 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> Agree. This patch need to be carefully verified. Current experiments just
> show that it is promising direction for improvement. I'll come with better
> version of this patch.
>
> Also, after testing on larg
On 27 November 2015 at 15:52, Dmitry Ivanov wrote:
Currently there is no way to backup 'pg_statistic' because columns of
> 'anyarray' type cannot be reconstructed solely with their textual
> representation. Meanwhile, all that is needed to solve this problem is a
> small
> extension capable of re
Hi all,
I found some lacks of tab-completion for RLS in 9.5.
* ALTER POLICY [TAB]
I expected to appear the list of policy name, but nothing is appeared.
* ALTER POLICY hoge_policy ON [TAB]
I expected to appear the list of table name related to specified policy,
but all table names are appear
Hi,
On 2015-12-04 21:57:54 +0900, Michael Paquier wrote:
> On Fri, Dec 4, 2015 at 5:10 PM, Andres Freund wrote:
> >> Let's go for XLOG_FPI_FLUSH.
> >
> > I think the other way is a bit better, because we can add new flags
> > without changing the WAL format.
>
> Hm. On the contrary, I think that
On 2015-12-03 22:09:43 +0100, Andres Freund wrote:
> On 2015-11-20 16:11:15 +0900, Michael Paquier wrote:
> > + if (bkpb.fork == INIT_FORKNUM)
> > + {
> > + SMgrRelation srel;
> > + srel = smgropen(bkpb.node, InvalidBackendId);
> > +
Hi
We have registered two new buildfarm animals for RHEL 7 on PPC64 and
PPC64LE (Little Endian). The configure for 9.3, 9.2 and 9.1 failed on
ppc64le with the error "error: cannot guess build type; you must specify
one". This is because config.guess for these branches don't expect the arch
to be p
On Tue, Dec 8, 2015 at 7:18 PM, Kyotaro HORIGUCHI
wrote:
> At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier
> wrote in
>
> > Regarding the patch, I
> > would tend to think that we should just reject it and try to cruft
> > something that could be more pluggable if there is really a need.
> >
On Tue, Dec 8, 2015 at 6:31 PM, Kyotaro HORIGUCHI
wrote:
>
> Thank you for looking on this and the comment.
>
> At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier
> wrote in
>
> > On Thu, Nov 26, 2015 at 2:45 PM, Kyotaro HORIGUCHI
> > wrote:
> > > What do you think about this solution?
> >
>
On 2015/12/08 17:27, Ashutosh Bapat wrote:
On Thu, Dec 3, 2015 at 12:36 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
Generating paths
A join between two foreign relations is considered safe to push
down if
4. The j
On 2015-12-04 21:55:29 -0500, Noah Misch wrote:
> On Thu, Dec 03, 2015 at 07:03:21PM +0100, Andres Freund wrote:
> > Sorry, but I really just want to see these changes as iterative patches
> > ontop of 9.5/HEAD instead of this process. I won't revert the reversion
> > if you push it anyway, but I t
Hi,
Attached is a small patch to adjust a comment in setrefs.c; in
set_foreignscan_references, fdw_recheck_quals also gets adjusted to
reference foreign scan tuple, in case of a foreign join, so I added
"etc.", to a comment there, as the comment in case of a simple foreign
table scan.
Best regard
On Tue, Dec 8, 2015 at 1:04 PM, Andres Freund wrote:
> On 2015-12-08 12:53:49 +0300, Alexander Korotkov wrote:
> > This is why atomic increment *could be* cheaper than loop over CAS and,
> it
> > worth having experiments. Another idea is that we can put arbitrary
> logic
> > between lwarx and s
Hello,
At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier
wrote in
> On Fri, Dec 4, 2015 at 6:06 PM, Pavel Stehule wrote:
> > long time I am dream about integrating Lua to psql
> >
> > It is fast enough for these purpose and can be used for custom macros, ..
>
> Things are perhaps digressing
Hi,
On 2015-12-08 12:53:49 +0300, Alexander Korotkov wrote:
> This is why atomic increment *could be* cheaper than loop over CAS and, it
> worth having experiments. Another idea is that we can put arbitrary logic
> between lwarx and stwcx. Thus, we can implement PinBuffer using single loop
> of
On 07/12/15 16:44, Simon Riggs wrote:
> There are many optimizations we might adopt, yet planning time is a factor.
> It seems simple enough to ignore more complex optimizations if we have
> already achieved a threshold cost (say 10). Such a test would add nearly
> zero time for the common case. We
Thank you for looking on this and the comment.
At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier
wrote in
> On Thu, Nov 26, 2015 at 2:45 PM, Kyotaro HORIGUCHI
> wrote:
> > What do you think about this solution?
>
>
I believe I haven't ripped off any in CC: list or In-Reply-To and
Reference
Hello, thank you for reviewing.
# I injured at fingertip, It's quite nuisance and make me more
# slower to type in..
I posted another patch to totally refactor psql-complete so I
don't put revised patch of this for now but this discussion has
an importance for me so please continue to discuss on
1 - 100 of 101 matches
Mail list logo
