Hi,
2014-07-04 19:05 GMT+09:00 Andres Freund :
> On 2014-07-04 11:59:23 +0200, Fabien COELHO wrote:
> >
> > >Yea. I certainly disagree with the patch in it's current state because
> it
> > >copies the same 15 lines several times with a two word difference.
> > >Independent of whether we want thos
On Mon, Feb 10, 2014 at 10:59 AM, Alexander Korotkov
wrote:
> Done. Patch is splitted.
I took a quick look at this.
Have you thought about making your new cmpSortSkipCols() function not
use real comparisons? Since in the circumstances in which this
optimization is expected to be effective (e.g.
On Sun, Jul 13, 2014 at 2:39 AM, Magnus Hagander
> Applied, thanks!.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> 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).
> -- But in my opinion, if histograms and mcv both are e
On Mon, Jun 30, 2014 at 1:43 PM, Michael Paquier
wrote:
>
>
>
> On Mon, Jun 30, 2014 at 7:05 PM, Asif Naeem wrote:
>> Patch looks good to me. I think it is ready for committer. Thanks.
> Thanks for the extra checks and for taking the time to review it.
Applied, thanks!
--
Magnus Hagander
Me
On Fri, Jul 11, 2014 at 12:40:09PM +0300, Christoph Berg wrote:
> > > > > > I believe pg_upgrade itself still needs a fix. While it's not a
> > > > > > security problem to put the socket in $CWD while upgrading (it is
> > > > > > using -c unix_socket_permissions=0700), this behavior is pretty
> > >
On Sat, Jul 12, 2014 at 4:36 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> As an administrator, I find that you fairly often want to know what
>> your current connections are actually using as SSL parameters, and
>> there is currently no other way than gdb to find that out - something
>> we de
Magnus Hagander writes:
> As an administrator, I find that you fairly often want to know what
> your current connections are actually using as SSL parameters, and
> there is currently no other way than gdb to find that out - something
> we definitely should fix.
I'm wondering whether it's such a
Hi,
On 2014-06-23 19:57:21 -0700, Jeff Janes wrote:
> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
> new file mode 100644
> index be5c3c5..dcd1b7d
> *** a/src/bin/psql/tab-complete.c
> --- b/src/bin/psql/tab-complete.c
> *** psql_completion(const char *text, i
As an administrator, I find that you fairly often want to know what
your current connections are actually using as SSL parameters, and
there is currently no other way than gdb to find that out - something
we definitely should fix.
You can find it out today through libpq (the PQgetssl functions), t
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 crime attacks. ISTM we should be
making this easier for the user.
On Fri, Jul 11, 2014 at 1:10 PM, Magnus Hagander wrote:
> On Fri, Jul 11, 2014 at 12:01 AM, Vik Fearing wrote:
>> On 07/10/2014 09:32 PM, Magnus Hagander wrote:
>>> It seems psql is missing autocomplete entries for LC_COLLATE and
>>> LC_CTYPE for the CREATE DATABASE command. Attached patch adds t
On 12.7.2014 11:39, Simon Riggs wrote:
> On 11 July 2014 18:25, Tomas Vondra wrote:
>
>> Turns out getting this working properly will quite complicated.
>
> Lets keep this patch simple then. Later research can be another patch.
Well, the dense allocation is independent to the NTUP_PER_BUCKET
ch
Hi Robert,
Thank you for checking this!
I've added it to commitfest.
https://commitfest.postgresql.org/action/patch_view?id=1507
regards,
Tomonari Katsumata
2014-07-12 6:07 GMT+09:00 Robert Haas :
> On Thu, Jul 10, 2014 at 2:52 AM, Tomonari Katsumata
> wrote:
> > Several couple
On 11 July 2014 18:25, Tomas Vondra wrote:
> Turns out getting this working properly will quite complicated.
Lets keep this patch simple then. Later research can be another patch.
In terms of memory pressure, having larger joins go x4 faster has a
much more significant reducing effect on memory
15 matches
Mail list logo