On 12 July 2014 23:25, Emre Hasegeli Wrote,
> > I have one last comment, after clarifying this I can move it to
> "ready for committer".
> > 1. In networkjoinsel, For avoiding the case of huge statistics, only
> some of the values from mcv and histograms are used (calculated using
> SQRT).
> > --
At 2014-07-14 16:48:09 -0400, alvhe...@2ndquadrant.com wrote:
>
> The attachments are there on the archives, and also on my mbox -- and
> unlike Robert, I was not copied. I think this is a problem on
> Abhijit's end.
Yes, it is. I apologise for the noise.
-- Abhijit
--
Sent via pgsql-hackers
(2014/07/14 21:01), Fujii Masao wrote:
On Fri, Jul 11, 2014 at 7:21 PM, Fujii Masao wrote:
On Fri, Jul 11, 2014 at 5:45 PM, Etsuro Fujita
wrote:
I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
blocks for a bitmap heap scan when both the numbers of exact/lossy pages
retri
On Mon, Jul 14, 2014 at 3:31 PM, Christoph Berg wrote:
>
> Oh I wasn't aware of the wiki page, I had just read the old thread.
> Thanks for the pointer.
>
:-)
Thanks again for your review!
> > > > diff --git a/doc/src/sgml/ref/alter_table.sgml
> > b/doc/src/sgml/ref/alter_table.sgml
> > > > in
(2014/07/14 19:46), Fujii Masao wrote:
On Mon, Jul 14, 2014 at 7:31 PM, Shigeru Hanada
wrote:
Fujita-san,
2014-07-11 18:22 GMT+09:00 Etsuro Fujita :
I think the following comment for store_returning_result() in
postgres_fdw.c is not right.
/* PGresult must be released before leaving thi
On Sun, Jul 13, 2014 at 2:27 AM, Mitsumasa KONDO
wrote:
> I still agree with Fabien-san. I cannot understand why our logical proposal
> isn't accepted...
Well, I think the feedback has been pretty clear, honestly. Here's
what I'm unhappy about: I can't understand what these options are
actually
On Sat, Jul 12, 2014 at 8:49 AM, Magnus Hagander wrote:
> It's today really hard to figure out if your SSL connection is
> actually *using* SSL compression. This got extra hard when we the
> default value started getting influenced by environment variables at
> least on many platforms after the cr
Fabrízio de Royes Mello wrote:
> On Fri, May 16, 2014 at 2:03 AM, Fabrízio de Royes Mello <
> fabriziome...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Are there some reason to don't show the tablespace size in the \db+
> > psql command?
>
> The attached patch show tablespace size in \db+ psql comma
Jaime Casanova wrote:
> Attached is a patch moving the reloptions of views into its own structure.
> i also created a view_reloptions() function in order to not use
> heap_reloptions() for views, but maybe that was too much?
No, that was part of what I was thinking too -- I have pushed this now.
On 07/14/2014 04:46 PM, Robert Haas wrote:
On Mon, Jul 14, 2014 at 4:39 PM, Andrew Dunstan wrote:
Is there any reasonable alternative? That is, if you have a function
returning SETOF record, and the details of the record type aren't
specified, is there anything you can do other than error out
Is there an easy way to get a list of held lwlocks out of gdb attached to a
core dump (or for that matter attached to a live process)?
I can try manually walking the internal data structure, but I am hoping for
something analogous to the way you get memory contexts:
(gdb) p MemoryContextStats(Top
Robert Haas wrote:
> On Mon, Jul 14, 2014 at 6:20 AM, Abhijit Menon-Sen
> wrote:
> > At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
> >> > > Hm. Not sure what you're ACKing here ;).
> >> >
> >> > The idea of giving the unallocated memory a NULL key.
> >>
> >> Ok. A new version of the
On Mon, Jul 14, 2014 at 4:39 PM, Andrew Dunstan wrote:
>> Is there any reasonable alternative? That is, if you have a function
>> returning SETOF record, and the details of the record type aren't
>> specified, is there anything you can do other than error out like
>> this?
>
> Not that I can see.
On 07/14/2014 03:44 PM, Robert Haas wrote:
populate_record_worker in jsonfuncs.c says this:
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("fu
On Wed, Jul 9, 2014 at 5:16 PM, Alvaro Herrera wrote:
> The way it works now, each opclass needs to have three support
> procedures; I've called them getOpers, maybeUpdateValues, and compare.
> (I realize these names are pretty bad, and will be changing them.)
> getOpers is used to obtain informat
populate_record_worker in jsonfuncs.c says this:
if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context "
On 2014-07-11 09:55:34 -0400, Bruce Momjian wrote:
> On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
> > > Uh, why does this need to be in ALTER TABLE? Can't this be part of
> > > table creation done by pg_dump?
> >
> > Uh, I think you need to read the thread. We have to delay the
Re: Andres Freund 2014-07-12 <20140712135128.gd3...@awork2.anarazel.de>
> I'm also not really happy with the fact that we only complete a single
> search_path item. But it's not easy to do better and when looking around
> other places (e.g. DROP TABLE) don't support it either.
The difference is th
Re: Noah Misch 2014-07-12 <20140712170151.ga1985...@tornado.leadboat.com>
> Thanks. Preliminary questions:
>
> > +#ifdef HAVE_UNIX_SOCKETS
> > +/* make_temp_sockdir() is invoked at most twice from pg_upgrade.c via
> > get_sock_dir() */
> > +#define MAX_TEMPDIRS 2
> > +static int n_tempdirs = 0;
On Mon, Jul 14, 2014 at 11:26:19AM -0400, Robert Haas wrote:
> On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian wrote:
> > On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
> >> > Uh, why does this need to be in ALTER TABLE? Can't this be part of
> >> > table creation done by pg_dump?
Re: Fabrízio de Royes Mello 2014-07-12
> > ... that being the non-WAL-logging with wal_level=minimal, or more?
>
> This is the first of additional goals, but we have others. Please see [1].
Oh I wasn't aware of the wiki page, I had just read the old thread.
Thanks for the pointer.
> > > diff
On Mon, Jul 14, 2014 at 11:03 AM, Claudio Freire wrote:
> Are those numbers measured on MAC's strxfrm?
>
> That was the one with suboptimal entropy on the first 8 bytes.
No, they're from a Linux system which uses glibc 2.19. The
optimization will simply be not used on implementations that don't
m
On Mon, Jul 14, 2014 at 6:20 AM, Abhijit Menon-Sen wrote:
> At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
>> > > Hm. Not sure what you're ACKing here ;).
>> >
>> > The idea of giving the unallocated memory a NULL key.
>>
>> Ok. A new version of the patches implementing that are attac
On Mon, Jul 14, 2014 at 2:53 PM, Peter Geoghegan wrote:
> My concern is that it won't be worth it to do the extra work,
> particularly given that I already have 8 bytes to work with. Supposing
> I only had 4 bytes to work with (as researchers writing [2] may have
> only had in 1994), that would le
On 07/13/2014 10:35 PM, Magnus Hagander wrote:
> On Sun, Jul 13, 2014 at 10:32 PM, Stefan Kaltenbrunner
> wrote:
>> On 07/12/2014 03:08 PM, Magnus Hagander wrote:
>>> As an administrator, I find that you fairly often want to know what
>>> your current connections are actually using as SSL paramete
On Thu, Jun 12, 2014 at 2:09 PM, Peter Geoghegan wrote:
> Right. It was a little bit incautious of me to say that we had the
> full benefit of 8 bytes of storage with "en_US.UTF-8", since that is
> only true of lower case characters (I think that FreeBSD can play
> tricks with this. Sometimes, it
On Mon, Jul 14, 2014 at 12:26 PM, Robert Haas wrote:
>
> On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian wrote:
> > On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
> >> > Uh, why does this need to be in ALTER TABLE? Can't this be part of
> >> > table creation done by pg_dump?
> >>
On 07/06/2014 10:11 AM, Andres Freund wrote:
Hi Steve,
Right. I thought about this for a while, and I think we should change
two things. For one, don't request replies here. It's simply not needed,
as this isn't dealing with timeouts. For another don't just check ->flush
< sentPtr but also &&
On 2014-07-14 11:24:26 -0400, Robert Haas wrote:
> On Sun, Jul 13, 2014 at 2:23 PM, Andres Freund wrote:
> > The actual if (lock != NULL) bit costs significant amounts of cycles?
> > I'd have assumed that branch prediction takes care of that. Or is it
> > actually the icache not keeping up? Did yo
On Fri, Jul 11, 2014 at 9:55 AM, Bruce Momjian wrote:
> On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
>> > Uh, why does this need to be in ALTER TABLE? Can't this be part of
>> > table creation done by pg_dump?
>>
>> Uh, I think you need to read the thread. We have to delay the
On Sun, Jul 13, 2014 at 2:23 PM, Andres Freund wrote:
> The actual if (lock != NULL) bit costs significant amounts of cycles?
> I'd have assumed that branch prediction takes care of that. Or is it
> actually the icache not keeping up? Did you measure icache vs. dcache
> misses?
> Have you played w
True. Both variants are legal, and most people won't ever notice. I
stumbled across this while writing a test case for a transaction helper
that sets/restores search_path before committing. The test was to simply
compare the string values of `SHOW search_path;` before `BEGIN
TRANSACTION;` and after
On Fri, Jul 11, 2014 at 2:43 PM, Tom Lane wrote:
> This example in the regression database is a simplified version of a bug
> I was shown off-list:
>
> regression=# select (
> select q from
> ( select 1,2,3 where f1>0
> union all
> select 4,5,6.0 where f1<=0
> ) q
> )
> from int4_tbl;
> ERROR:
On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin
wrote:
> I noticed a minor inconsistency with the search_path separator used in the
> default configuration.
>
> The schemas of any search_path set using `SET search_path TO...` are
> separated by ", " (comma, space), while the default value is onl
On Mon, Jul 14, 2014 at 4:02 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Mon, 14 Jul 2014 11:01:52 +0530, Amit Kapila
wrote in
> > On Fri, Jun 13, 2014 at 1:11 PM, Kyotaro HORIGUCHI <
> > horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > I am bit worried about the extra cycles
David Rowley writes:
> On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane wrote:
>> Ugh. I'm back to being discouraged about the usefulness of the
>> optimization.
> Are you worried about the planning overhead of the not null checks, or is
> it more that you think there's a much smaller chance of a real
On Mon, Jul 14, 2014 at 3:21 AM, Abhijit Menon-Sen
wrote:
>
> Hi.
>
> We're now at the "nearly done" stage of the first 9.5 CF.
>
> Twenty-four patches have been committed so far, and five more are ready
> for committer (and of those, four are small). Thirty patches are still
> marked "needs revie
At 2014-07-14 07:55:34 -0400, t...@sss.pgh.pa.us wrote:
>
> I'd vote for rejecting and annotating the TODO item with a link to
> this thread.
I've marked the patch as rejected and edited the TODO list to remove the
"easy". There was already a link to this thread there.
Thank you.
-- Abhijit
--
On Fri, Jul 11, 2014 at 7:21 PM, Fujii Masao wrote:
> On Fri, Jul 11, 2014 at 5:45 PM, Etsuro Fujita
> wrote:
>> I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
>> blocks for a bitmap heap scan when both the numbers of exact/lossy pages
>> retrieved by the node are zero. Su
Abhijit Menon-Sen writes:
> Do we have any consensus on this patch?
> I took a quick look at it because no review was posted. The patch itself
> does what it claims to, but from the discussion it doesn't seem like we
> want the feature; or perhaps we only don't want it in its present form.
Re-re
On Mon, Jul 14, 2014 at 7:31 PM, Shigeru Hanada
wrote:
> Fujita-san,
>
> 2014-07-11 18:22 GMT+09:00 Etsuro Fujita :
>> I think the following comment for store_returning_result() in
>> postgres_fdw.c is not right.
>>
>> /* PGresult must be released before leaving this function. */
>>
>> I think
Thank you for reviewing, the revised patch will come later.
At Mon, 14 Jul 2014 11:01:52 +0530, Amit Kapila wrote
in
> On Fri, Jun 13, 2014 at 1:11 PM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
> >
> > Hello, This is the continuation from the last CF.
> >
> > This patch inte
Fujita-san,
2014-07-11 18:22 GMT+09:00 Etsuro Fujita :
> I think the following comment for store_returning_result() in
> postgres_fdw.c is not right.
>
> /* PGresult must be released before leaving this function. */
>
> I think PGresult should not be released before leaving this function *on
>
At 2014-05-08 15:28:22 +0200, and...@2ndquadrant.com wrote:
>
> > > Hm. Not sure what you're ACKing here ;).
> >
> > The idea of giving the unallocated memory a NULL key.
>
> Ok. A new version of the patches implementing that are attached.
> Including a couple of small fixups and docs. The latter
Hi.
Do we have any consensus on this patch?
I took a quick look at it because no review was posted. The patch itself
does what it claims to, but from the discussion it doesn't seem like we
want the feature; or perhaps we only don't want it in its present form.
So which is more appropriate, retur
Kaigai-san,
The v3 patch had conflict in src/backend/tcop/utility.c for newly
added IMPORT FOREIGN SCHEMA statement, but it was trivial.
2014-07-08 20:55 GMT+09:00 Kouhei Kaigai :
> * System catalog name was changed to pg_custom_plan_provider;
> that reflects role of the object being defined.
Hello, Let me apologize for continuing the discussion even though
the deadline is approaching.
At Fri, 11 Jul 2014 09:49:55 +0900, Michael Paquier
wrote in
> Updated patches attached.
>
> On Thu, Jul 10, 2014 at 7:13 PM, Kyotaro HORIGUCHI
> wrote:
> >
> > The usage of this is a bit irregular
On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane wrote:
> David Rowley writes:
> > I had another look at this and it appears you were right the first time,
> we
> > need to ensure there's no NULLs on both sides of the join condition.
>
> Ugh. I'm back to being discouraged about the usefulness of the
>
48 matches
Mail list logo
