> On 27/08/15 13:36, Kouhei Kaigai wrote:
> [...]
> > My measurement is done on v9.5 based system. So, it also seems to me
> > replacement of CHAR(n) by VARCHAR(n) will make sense.
>
> Is there any reason to not simply use text instead of CHAR(n) or VARCHAR(n)?
>
Text is also welcome, of course.
-
On 27/08/15 13:36, Kouhei Kaigai wrote:
[...]
My measurement is done on v9.5 based system. So, it also seems to me
replacement of CHAR(n) by VARCHAR(n) will make sense.
Is there any reason to not simply use text instead of CHAR(n) or VARCHAR(n)?
[...]
-Gavin
--
Sent via pgsql-hackers maili
> On 2015/08/26 18:01, Kouhei Kaigai wrote:
> >>> You may think execution of alternative plan is the best way for EPQ
> >>> rechecks,
> >>> however, other folks may think their own implementation is the best for
> >>> EPQ
> >>> rechecks. I never argue which approach is better.
> >>> What I point
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Thursday, August 27, 2015 9:03 AM
> To: Qingqing Zhou
> Cc: Kaigai Kouhei(海外 浩平); Greg Stark; PostgreSQL-development
> Subject: Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable
> plan
>
> Qingqing Z
Hi all,
As of now, file access functions in genfile.c can only be used by
superusers. This proposal is to relax those functions so as
replication users can use them as well. Here are the functions aimed
by this patch:
- pg_stat_file
- pg_read_binary_file
- pg_read_file
- pg_ls_dir
The main argumen
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Thursday, August 27, 2015 8:31 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Greg Stark; PostgreSQL-development
> Subject: Re: [HACKERS] Our trial to TPC-
On Wed, Aug 26, 2015 at 12:49:46PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > A buildfarm machine would be mandatory, too.
>
> That, however, is not negotiable.
Right. I think the still-open question around PostgreSQL on Alpha is whether
9.1 through 9.4 are meaningfully supported there
I wrote:
> What I had in mind in <38448.1430519...@sss.pgh.pa.us> was to convert CTEs
> into plain subqueries during the prepjointree phase, either just before
> or as part of the pull_up_subqueries pass (since you'd want the converted
> subquery to be flattened if possible).
After looking at the
Qingqing Zhou writes:
> Above two queries essentially the same, but the second one is a
> non-optimal plan. The reason is that how my patch works: it put a
> substitution in front of SS_process_ctes():
>/*
> * If there is a WITH list, process each WITH query and build an initplan
> ! * SubP
> On 2015-08-26 00:55:48 +, Kouhei Kaigai wrote:
> > As Tom pointed out, the primary reason why CustomScan required provider
> > to save its private data on custom_exprs/custom_private were awareness
> > of copyObject().
>
> Well, a callback brings that with it as well. I do think it makes sen
On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai wrote:
> I think SortSupport logic provides a reasonable way to solve this
> kind of problem. For example, btint4sortsupport() informs a function
> pointer of the fast version of comparator (btint4fastcmp) which takes
> two Datum argument without indi
On 08/26/2015 03:57 AM, Tom Lane wrote:
Is it unreasonable of me to ask for the Windows behavior to be fixed at
the same time? I dunno. It's perhaps less broken than the Unix behavior,
but that doesn't make it desirable. OTOH it might be a significantly
larger patch, and I confess I'm not even
On 2015-08-26 00:55:48 +, Kouhei Kaigai wrote:
> As Tom pointed out, the primary reason why CustomScan required provider
> to save its private data on custom_exprs/custom_private were awareness
> of copyObject().
Well, a callback brings that with it as well. I do think it makes sense
to *allow
Simon Riggs writes:
> On 25 August 2015 at 21:51, Tom Lane wrote:
>> I don't mean to dismiss the potential for further optimization inside
>> XidInMVCCSnapshot (for instance, the one-XID-cache idea sounds promising);
>> but I think that's material for further research and a separate patch.
> Pat
On Wed, Aug 26, 2015 at 11:58 AM, Bruce Momjian wrote:
> I am sorry it so long for me to address this. Peter brought it up in
> June, but I just wasn't around to address it cleanly before now. I am
> glad he reminded me.
Well, you got around to it eventually. Thanks.
--
Peter Geoghegan
--
On 2015-08-25 19:22:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think it was a noticeable mistake in the fdw case, but we already
> > released with that. We shouldn't make the same mistake twice.
>
> I don't agree that it was a mistake, and I do think there is value in
> consistency.
On Wed, Aug 19, 2015 at 10:32 AM, Qingqing Zhou
wrote:
> On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai wrote:
>> BTW, did you register the patch on the upcoming commit-fest?
>>
> Not yet, it is in WIP status.
>
While I am working on the patch, I found some issues and resort help
here. Patch att
On Wed, Aug 26, 2015 at 4:31 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
>
> > Why this patch was reverted one day after applied [1]? I didn't see any
> > discussion around it.
>
> Contributors whose patches are getting committed should really subscribe
> to pgsql-committers.
>
O
On Wed, Aug 26, 2015 at 4:30 PM, Andres Freund wrote:
>
> On 2015-08-26 16:24:31 -0300, Fabrízio de Royes Mello wrote:
> > Why this patch was reverted one day after applied [1]? I didn't see any
> > discussion around it.
>
> http://www.postgresql.org/message-id/23918.1409010...@sss.pgh.pa.us
Tha
Fabrízio de Royes Mello wrote:
> Why this patch was reverted one day after applied [1]? I didn't see any
> discussion around it.
Contributors whose patches are getting committed should really subscribe
to pgsql-committers.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL
On 2015-08-26 16:24:31 -0300, Fabrízio de Royes Mello wrote:
> Why this patch was reverted one day after applied [1]? I didn't see any
> discussion around it.
http://www.postgresql.org/message-id/23918.1409010...@sss.pgh.pa.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 26 August 2015 at 20:24, Fabrízio de Royes Mello wrote:
>
> On Mon, Aug 25, 2014 at 6:07 PM, Bruce Momjian wrote:
> >
> > On Fri, Aug 22, 2014 at 10:04:50PM -0400, Bruce Momjian wrote:
> > > On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> > > > On Fri, Aug 22, 2014 at 2:33 PM,
On Mon, Aug 25, 2014 at 6:07 PM, Bruce Momjian wrote:
>
> On Fri, Aug 22, 2014 at 10:04:50PM -0400, Bruce Momjian wrote:
> > On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> > > On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian
wrote:
> > > >> Yes, you remember well. I will have to fi
On Wed, Aug 26, 2015 at 02:47:14PM -0400, Bruce Momjian wrote:
> On Wed, Aug 26, 2015 at 10:10:01AM -0700, Peter Geoghegan wrote:
> > On Wed, Aug 26, 2015 at 7:33 AM, Bruce Momjian wrote:
> > > I have applied the attached patch to document this in the data type docs.
> >
> > Thanks, but shouldn't
On Mon, Jul 27, 2015 at 04:10:14PM -0500, Jim Nasby wrote:
> >>Sure, but I don't think this makes it impossible to figure out who's
> >>locking who. I think the only thing you need other than the data in
> >>pg_locks is the conflicts table, which is well documented.
> >>
> >>Oh, hmm, one thing mis
On Wed, Aug 26, 2015 at 10:10:01AM -0700, Peter Geoghegan wrote:
> On Wed, Aug 26, 2015 at 7:33 AM, Bruce Momjian wrote:
> > I have applied the attached patch to document this in the data type docs.
>
> Thanks, but shouldn't varchar/text also be mentioned in the release
> notes, rather than "char
Andres Freund writes:
> But I really strongly object to re-introducing alpha support. Having to
> care about data dependency barriers is a huge pita, and it complicates
> code for everyone. And we'd have to investigate a lot of code to
> actually make it work reliably. For what benefit?
I hear yo
On Wed, Aug 26, 2015 at 7:33 AM, Bruce Momjian wrote:
> I have applied the attached patch to document this in the data type docs.
Thanks, but shouldn't varchar/text also be mentioned in the release
notes, rather than "character fields"?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing li
On 2015-08-26 12:49:46 -0400, Tom Lane wrote:
> As far as that goes, we do have fallback atomics code that's supposed to
> work on anything (and not be unusably slow). So in principle,
> resurrecting the Alpha spinlock code ought to be enough to get back to the
> previous level of support. Coding
On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera
wrote:
> Jim Nasby wrote:
>
>> I think things like pageinspect are very different; I really can't see any
>> use for those beyond debugging (and debugging by an expert at that).
>
> I don't think that necessarily means it must continue to be in cont
Alvaro Herrera writes:
> Michael Cree wrote:
>> That is disappointing to hear. Why is that? It is still in use on
>> Alpha. What is the maintenance load for keeping the Alpha arch
>> specific code?
> The amount of code that was removed by the commit isn't all that much:
> http://git.postgresql
On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > OK. So, as we mentioned before, if we need to expose something of am
> > parameters at SQL-level then we need to write special functions which
> would
> > call amhandler and expose it.
> > Did we come to the agreem
On 08/25/2015 06:21 PM, Jim Nasby wrote:
CREATE FUNCTION magsum( c c[] ) RETURNS float LANGUAGE sql AS $$
SELECT sum(sqrt(c.r^2 + c.i^2)) FROM unnest(c) c
$$;
SELECT magsum( array[row(2.1, 2.1), row(2.2,2.2)] );
SELECT magsum( array[row(2.1, 2.1), row(2.2,2.2)]::c[] );
cheers
andrew
--
Michael Cree writes:
> On Tue, Aug 25, 2015 at 06:09:17PM -0400, Tom Lane wrote:
>> It'd be easy enough to s/rmb/mb/ in 9.4 ... but not sure it's worth
>> the trouble, since we're desupporting Alpha as of 9.5 anyway.
> That is disappointing to hear. Why is that? It is still in use on
> Alpha.
Michael Cree wrote:
> On Tue, Aug 25, 2015 at 06:09:17PM -0400, Tom Lane wrote:
> > Oh really? If rmb were a figment of someone's imagination, it would
> > explain the build failure (although not why nobody's reported it till
> > now).
>
> I reported the failure to build on Alpha, with an explan
On Tue, Aug 25, 2015 at 06:09:17PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Well, strictly speaking, there were no uses of pg_read_barrier until 9.4.
> >> However, pg_write_barrier (which used "wmb") was in use since 9.2; so
> >> unless you're claiming your assemble
Alexander Korotkov writes:
> OK. So, as we mentioned before, if we need to expose something of am
> parameters at SQL-level then we need to write special functions which would
> call amhandler and expose it.
> Did we come to the agreement on this solution?
I think we were agreed that we should wr
Hi
2015-08-25 17:21 GMT+02:00 Tom Lane :
> Jim Nasby writes:
> > What I've had problems with is trying to correlate psql specified
> > connection attributes with things like DBI. It would be nice if there
> > was a way to get a fully formed connection URI for the current
> connection.
>
> Yeah,
* Joe Conway (m...@joeconway.com) wrote:
> On 08/26/2015 06:33 AM, Stephen Frost wrote:
> > * Joe Conway (m...@joeconway.com) wrote:
> >> Issues needing comment: a.) Which items need hiding from
> >> non-superusers and should the value be redacted or the entire
> >> result set row be suppressed?
>
On Thu, Aug 20, 2015 at 04:07:36PM -0700, Peter Geoghegan wrote:
> On Sat, Jun 13, 2015 at 3:53 PM, Peter Geoghegan wrote:
> > I think we should really address this. Attached patch adds a new
> > release note item for it. It also adds to the documentation that
> > explains why users should prefer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2015 06:33 AM, Stephen Frost wrote:
> * Joe Conway (m...@joeconway.com) wrote:
>> Issues needing comment: a.) Which items need hiding from
>> non-superusers and should the value be redacted or the entire
>> result set row be suppressed?
>
> I
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Needs planner work and tests of that. ALTER TABLE etc can wait.
The new stat
On 18 August 2015 at 11:30, Amit Langote
wrote:
> I would like propose $SUBJECT for this development cycle. Attached is a
> WIP patch that implements most if not all of what's described below. Some
> yet unaddressed parts are mentioned below, too. I'll add this to the
> CF-SEP.
>
Thanks for wor
On Tue, Aug 25, 2015 at 7:20 PM, Tom Lane wrote:
> Jim Nasby writes:
> > On 8/25/15 10:56 AM, Tom Lane wrote:
> >> I'm good with this as long as all the things that get stored in pg_am
> >> are things that pg_class.relam can legitimately reference. If somebody
> >> proposed adding an "access me
* Joe Conway (m...@joeconway.com) wrote:
> Issues needing comment:
> a.) Which items need hiding from non-superusers and should the value be
> redacted or the entire result set row be suppressed?
I'm of the opinion that we need to at least redact it and that what we
should do is simply suppres
Hi
2015-08-26 13:12 GMT+02:00 Pavel Stehule :
> Hi
>
> 2015-07-29 21:05 GMT+02:00 Pavel Stehule :
>
>> Hi
>>
>> here is proof concept patch
>>
>> It should be cleaned, but it demonstrates a work well
>>
>> [pavel@localhost psql]$ ./psql -C 'select 10 x; select 20 y;' -C "\l"
>> postgres
>> x
>
Hi
if (options.single_txn && options.action != ACT_FILE &&
options.action == ACT_NOTHING)
{
fprintf(stderr, _("%s: -1 can only be used in
non-interactive mode\n"), pset.progname);
exit(EXIT_FAILURE);
}
the expression should be probably only?
other example related to using psql in pipeline
[pavel@localhost psql]$ ./psql postgres -q -g "vacuum analyze pg_attribute"
-g "\echo :DBNAME"
postgres
Hi
2015-07-29 21:05 GMT+02:00 Pavel Stehule :
> Hi
>
> here is proof concept patch
>
> It should be cleaned, but it demonstrates a work well
>
> [pavel@localhost psql]$ ./psql -C 'select 10 x; select 20 y;' -C "\l"
> postgres
> x
>
> 10
> (1 row)
>
> y
>
> 20
> (1 row)
>
>
On 26 August 2015 at 11:40, Amit Kapila wrote:
> On Tue, Aug 25, 2015 at 2:21 PM, Simon Riggs
> wrote:
>
>> On 22 August 2015 at 15:14, Andres Freund wrote:
>>
>
>
>> TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which
>>> writes an 8 byte variable (the lsn). That's not safe.
On 2015/08/26 18:01, Kouhei Kaigai wrote:
You may think execution of alternative plan is the best way for EPQ rechecks,
however, other folks may think their own implementation is the best for EPQ
rechecks. I never argue which approach is better.
What I point out is freedom/flexibility of implemen
On Tue, Aug 25, 2015 at 2:21 PM, Simon Riggs wrote:
> On 22 August 2015 at 15:14, Andres Freund wrote:
>
> TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which
>> writes an 8 byte variable (the lsn). That's not safe.
>>
>
> Agreed, thanks for spotting that.
>
> I see this as t
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Wednesday, August 26, 2015 5:38 PM
> To: Kaigai Kouhei(海外 浩平); Robert Haas
> Cc: PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> On 2015/08/26 17:05, Kouhe
On 2015/08/26 17:05, Kouhei Kaigai wrote:
On 2015/08/26 16:07, Kouhei Kaigai wrote:
Even if we enforce them a new interface specification comfortable to RDBMS,
we cannot guarantee it is also comfortable to other type of FDW drivers.
Specifically, what kind of points about the patch are specif
> On 2015/08/26 16:07, Kouhei Kaigai wrote:
> I wrote:
> >> Maybe I'm missing something, but why do we need such a flexiblity for
> >> the columnar-stores?
>
> > Even if we enforce them a new interface specification comfortable to RDBMS,
> > we cannot guarantee it is also comfortable to other type
On Tue, Aug 25, 2015 at 4:39 PM, Michael Paquier
wrote:
> On Mon, Aug 10, 2015 at 4:34 PM, Heikki Linnakangas wrote:
>> Hello Hackers,
>>
>> There are a few "Needs Review" items remaining in the July commitfest.
>> Reviewers, please take action - you are holding up the commitfest.
>>
>> In additi
On 25 August 2015 at 21:51, Tom Lane wrote:
>
> I don't mean to dismiss the potential for further optimization inside
> XidInMVCCSnapshot (for instance, the one-XID-cache idea sounds promising);
> but I think that's material for further research and a separate patch.
>
Patch attached. Doesn't se
On Sun, Aug 23, 2015 at 10:47 PM, Pavel Stehule wrote:
> [blah]
>
> fixed
Moved to next CF 2015-09.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 20, 2015 at 11:25 AM, Tomas Vondra
wrote:
>
> On 08/20/2015 03:49 AM, Tomas Vondra wrote:
>>
>> Then on current master, I get these estimates (showing just rows,
>> because that's what matter):
>>
>> [...]
Moved to next CF 2015-09.
--
Michael
--
Sent via pgsql-hackers mailing list
On Mon, Aug 24, 2015 at 4:15 PM, Fabien COELHO wrote:
>
> [stuff]
Moved to next CF 2015-09.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015/08/26 16:07, Kouhei Kaigai wrote:
I wrote:
Maybe I'm missing something, but why do we need such a flexiblity for
the columnar-stores?
Even if we enforce them a new interface specification comfortable to RDBMS,
we cannot guarantee it is also comfortable to other type of FDW drivers.
S
On Mon, Mar 16, 2015 at 9:51 PM, Robert Haas wrote:
> On Wed, Mar 4, 2015 at 4:26 AM, Shigeru Hanada
> wrote:
>> Here is v4 patch of Join push-down support for foreign tables. This
>> patch requires Custom/Foreign join patch v7 posted by Kaigai-san.
>
> Hi,
>
> I just want to point out to the f
On Tue, Aug 25, 2015 at 2:25 PM, David Rowley
wrote:
> On 24 August 2015 at 14:29, Tom Lane wrote:
>>
>> David Rowley writes:
>> > I have to admit I don't much like it either, originally I had this as an
>> > extra property that was only seen in EXPLAIN VERBOSE.
>>
>> Seems like a reasonable des
On Sun, Jul 26, 2015 at 6:37 PM, Fabien COELHO wrote:
>
> Hello Heikki,
>
>>> As soon as we add more functions, the way they are documented needs to be
>>> reworked too; we'll need to add a table in the manual to list them.
>>
>>
>> Here is a v8 with "abs", "min", "max", "random", "gaussian" et
>>
On Wed, Aug 26, 2015 at 4:35 PM, Michael Paquier
wrote:
> Only HEAD is impacted, and attached is a patch to fix the problem.
Actually this version is better, I forgot to update a comment.
--
Michael
diff --git a/src/test/ssl/ServerSetup.pm b/src/test/ssl/ServerSetup.pm
index 8c1b517..79d948a 100
Hi all,
The following commit has broken the SSL test suite (embarrassing and
lonely moment):
commit 13d856e177e69083f543d6383eeda9e12ce3c55c
Author: Heikki Linnakangas
Date: Wed Jul 29 19:17:02 2015 +0300
Make TAP tests work on Windows.
[...]
*Michael Paquier*, reviewed by Noah Misch, some add
> > In addition, you may misunderstand the proposition of mine above.
> > You can check RelOptInfo->fdw_private on top of the GetForeignJoinPaths,
> > then, if it is second or later invocation, you can check cost of the
> > alternative path kept in the ForeignPath node previously constructed.
> > I
67 matches
Mail list logo