On Thu, Sep 03, 2015 at 01:15:47AM +0200, Andres Freund wrote:
> On 2015-09-02 17:03:46 -0400, Robert Haas wrote:
> > On Wed, Sep 2, 2015 at 4:50 PM, Andrew Dunstan wrote:
> > > Tell me what's needed and I'll look at creating a buildfarm test module
> > > for
> > > it.
> > It's not run by th
On 28 August 2015 at 09:33, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Tomas Vondra is now working on heavily-equipped multivariate
> statistics for OLAP usage. In contrast, this is a lightly
> implemented solution which calculates only the ratio between a
> rows estimated by c
On 5 September 2015 at 20:46, Bruce Momjian wrote:
> On Fri, Aug 28, 2015 at 05:33:34PM +0900, Kyotaro HORIGUCHI wrote:
> > Hello, this patch enables planner to be couscious of inter-column
> > correlation.
> >
> > Sometimes two or more columns in a table has some correlation
> > which brings und
Hello Horiguchi-san,
On 08/28/2015 10:33 AM, Kyotaro HORIGUCHI wrote:
Hello, this patch enables planner to be couscious of inter-column
correlation.
Sometimes two or more columns in a table has some correlation
which brings underestimate, which leads to wrong join method and
ends with slow exec
On 06/09/2015 01:39, Michael Paquier wrote:
>
> On Sun, Sep 6, 2015 at 5:11 AM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>> wrote:
>
> I just noticed that part of storage.sgml was not updated when 9.3
> introduced checksum (and removed pd_tli from PageHeaderData).
>
>
> Yep, see
Hello,
On 09/06/2015 10:24 AM, Simon Riggs wrote:
On 28 August 2015 at 09:33, Kyotaro HORIGUCHI
mailto:horiguchi.kyot...@lab.ntt.co.jp>> wrote:
Tomas Vondra is now working on heavily-equipped multivariate
statistics for OLAP usage. In contrast, this is a lightly
implemented solution
>I will sketch a simple implementation of parallel sorting based on the
>patch series that may be workable, and requires relatively little
>implementation effort compare to other ideas that were raised at
>various times:
Hello,
I've only a very superficial understanding on your work,
please apo
On Sun, Sep 6, 2015 at 1:51 AM, Marc Mamin wrote:
> Have you considered performances for cases where multiple CREATE INDEX are
> running in parallel?
> One of our typical use case are large daily tables (50-300 Mio rows) with up
> to 6 index creations
> that start simultaneously.
> Our servers h
Hi
I am sending little bit modified version.
1. sqlstate should be text, not boolean - a boolean is pretty useless
3. fixed formatting and code style
Questions:
I dislike the using empty message when message parameter is null. We have
to show some text or we have to disallow it?
Regards
Pavel
On Sep 6, 2015 10:31, "Tomas Vondra" wrote:
>
> 5) syntax
> -
> The syntax might be one of the pain points if we eventually decide to
commit the multivariate stats patch. I have no intention in blocking this
patch for that reasons, but if we might design the syntax to make it
compatible wi
Hi
attached patch with fixed broken error message
Regards
Pavel
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index b3b78d2..b7a2cc2
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*** postgres=# SELECT * FROM pg_xlogfile_nam
*** 17925,17
On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule
wrote:
> Hi
>
> attached patch with fixed broken error message
>
> Regards
>
> Pavel
>
Hi Pavel,
Thanks much for taking care of it. Patch looks great.
--
Regards,
Dinesh
manojadinesh.blogspot.com
On Sun, Sep 6, 2015 at 4:00 PM, dinesh kumar
wrote:
> On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule
> wrote:
>
>> Hi
>>
>> attached patch with fixed broken error message
>>
>> Regards
>>
>> Pavel
>>
>
> Hi Pavel,
>
> Thanks much for taking care of it. Patch looks great.
>
>
> Hi Pavel,
Could yo
2015-09-06 13:12 GMT+02:00 dinesh kumar :
>
> On Sun, Sep 6, 2015 at 4:00 PM, dinesh kumar
> wrote:
>
>> On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> attached patch with fixed broken error message
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>
>> Hi Pavel,
>>
>> Thanks much fo
On Sun, Sep 6, 2015 at 4:46 PM, Pavel Stehule
wrote:
>
>
> 2015-09-06 13:12 GMT+02:00 dinesh kumar :
>
>>
>> On Sun, Sep 6, 2015 at 4:00 PM, dinesh kumar
>> wrote:
>>
>>> On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule
>>> wrote:
>>>
Hi
attached patch with fixed broken error messag
On 2015-08-15 21:16:11 +0900, Michael Paquier wrote:
> Well, this has taken less time than I thought:
> =# CREATE_REPLICATION_SLOT toto PHYSICAL;
> slot_name | consistent_point | snapshot_name | output_plugin
> ---+--+---+---
> toto | 0/0
On Tue, Aug 18, 2015 at 11:36 PM, Marko Tiikkaja wrote:
> On 2015-08-15 17:55, I wrote:
>
>> The attached patch adds support for RADIUS passwords longer than 16
>> octets.
>>
>
> Improved the coding and comments a bit, new version attached.
Looks good to me. Applied, thanks!
As a note - psql
On 2015-08-10 07:03:02 +0100, Simon Riggs wrote:
> I was previously a proponent of (2) as a practical way forwards, but my
> proposal here today is that we don't do anything further on 2) yet, and
> seek to make progress on 5) instead.
>
> If 5) fails to bring a workable solution by the Jan 2016 C
Hi,
Here's a bunch of comments on this (hopefully the latest?) version of
the patch:
* I'm not sure I like the FileWrite & FlushBuffer API changes. Do you
forsee other callsites needing similar logic? Wouldn't it be just as
easy to put this logic into the checkpointing code?
* We don't do on
Hi,
On 2015-09-05 12:48:12 +0300, Ildus Kurbangaliev wrote:
> Another parts require a some discussion so I didn't touch them yet.
At this point I don't see any point in further review until these are
addressed.
> The idea to create an individual tranches for individual LWLocks have
> come from H
On 2015-09-04 23:44:21 +0100, Simon Riggs wrote:
> I see the need for both current wait information and for cumulative
> historical detail.
>
> I'm willing to wait before reviewing this, but not for more than 1 more CF.
>
> Andres, please decide whether we should punt to next CF now, based upon
>
Looks like the right time to post this patch.
It separates the Buffer LWLocks from the main LW locks, allowing them to
have different padding.
Tests showed noticeable/significant performance gain due to reduced false
sharing on main LWlocks, though without wasting memory on the buffer
LWlocks.
-
On Sun, Sep 6, 2015 at 8:32 PM, Andres Freund wrote:
> [fixes]
>
> Committed, thanks for the patch.
>
Visibly I missed one/two things when hacking out this stuff. Thanks for the
extra cleanup and the commit.
--
Michael
Hi,
On 2015-09-06 14:10:24 +0100, Simon Riggs wrote:
> It separates the Buffer LWLocks from the main LW locks, allowing them to
> have different padding.
>
> Tests showed noticeable/significant performance gain due to reduced false
> sharing on main LWlocks, though without wasting memory on the b
Hi,
Please find attached a v2 of the patch. See below for changes.
On 02/09/2015 15:53, Andres Freund wrote:
>
> Hi,
>
> On 2015-07-18 12:17:39 +0200, Julien Rouhaud wrote:
>> I didn't know that the thread must exists on -hackers to be able to add
>> a commitfest entry, so I transfer the threa
Hello Andres,
Here's a bunch of comments on this (hopefully the latest?)
Who knows?! :-)
version of the patch:
* I'm not sure I like the FileWrite & FlushBuffer API changes. Do you
forsee other callsites needing similar logic?
I foresee that the bgwriter should also do something more se
Here is a rebased two-part v11.
* We don't do one-line ifs;
I've found one instance.
function parameters are always in the same line as the function name
ISTM that I did that, or maybe I did not understand what I've done wrong.
--
Fabien.diff --git a/doc/src/sgml/config.sgml b/doc/src/sg
Hi
> Any suggestions/comments on this proposed approach?
>
This is interesting functionality - The same was requested by one important
Czech customer.
I'll do review
Regards
Pavel
On 2015-09-06 19:05, Fabien COELHO wrote:
Here is a rebased two-part v11.
function parameters are always in the same line as the function name
ISTM that I did that, or maybe I did not understand what I've done wrong.
I see one instance of this issue
+static int
+NextBufferToWrite(
+
On 09/05/2015 09:14 AM, Joe Conway wrote:
> On 09/05/2015 09:05 AM, Tom Lane wrote:
>> I wrote:
>>> If there are not major objections, I'll work on cleaning up and
>>> committing the patch.
>>
>> Pushed. I'm not too sure about the expected outputs for python other
>> than 2.6, nor for sepgsql, but
Hello Petr,
function parameters are always in the same line as the function name
ISTM that I did that, or maybe I did not understand what I've done wrong.
I see one instance of this issue
+static int
+NextBufferToWrite(
+ TableSpaceCheckpointStatus *spcStatus, int nb_spaces,
+ i
Hi
> postgres=# select pg_hba_lookup('postgres','all');
> pg_hba_lookup
> ---
> (84,local,"[""all""]","[""all""]",,,trust,{})
> (86,host,"[""all""]","[""all""]",127.0.0.1,,trust,{})
> (88,host,"[""all""]","[""all""]",::1
Joe Conway writes:
>> On 09/05/2015 09:05 AM, Tom Lane wrote:
>>> Pushed. I'm not too sure about the expected outputs for python other
>>> than 2.6, nor for sepgsql, but hopefully the buildfarm will provide
>>> feedback.
> One-liner required for sepgsql -- attached committed and pushed.
Thanks
First of all, I wish to thank all the participants of the discussion
for their useful suggestions and critics.
I see that people are really interested in this feature.
Now, list of syntax and behavior changes against original proposal:
1. There is similar feature in JDBC, so syntax of URL-style
On 09/02/2015 02:54 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote:
>>> I think trying to duplicate the exact strings isn't too nice an
>>> interface.
>>
>> Well, for pg_controldata, no, but what else would you do for pg_config?
>
> I was primarily l
On Sep 6, 2015, at 2:36 PM, and...@anarazel.de wrote:On 2015-09-05 12:48:12 +0300, Ildus Kurbangaliev wrote:Another parts require a some discussion so I didn't touch them yet.At this point I don't see any point in further review until these areaddressed.The idea to create an individual tranches for
On 2015-09-06 22:57:04 +0300, Ildus Kurbangaliev wrote:
> Ok, I've kept only one tranche for individual LWLocks
But you've added the lock names as a statically sized array to all
tranches? Why not just a pointer to an array that's either NULL ('not
individualy named locks') or appropriately sized?
On 2015-09-06 16:05:01 +0200, Fabien COELHO wrote:
> >Wouldn't it be just as easy to put this logic into the checkpointing code?
>
> Not sure it would simplify anything, because the checkpointer currently
> knows about buffers but flushing is about files, which are hidden from
> view.
It'd not re
On Thu, Sep 3, 2015 at 10:55 PM, Atsushi Yoshida
wrote:
> >> Can you give an "explain (analyze, buffers)" for each query? Maybe
> you have a corrupted index, and one query uses the index and the other does
> not.
>
>
> >
> > Index Scan using idx_attend_00 on attend (cost=0.29..627.20 rows=172
Hi all,
There is currently no in-core function to query the amount of
available and free space in a path of PGDATA, with something like that
for example:
SELECT * FROM pg_get_diskspace_info('pg_xlog');
total_space | free_space
-+
4812 MB | 3925 MB
(1 row)
This would
Michael Paquier writes:
> statvfs is part of the POSIX spec and is "normally" present on modern
> platforms (BSD, OSX, Linux and Solaris have it as far as I saw, still
> there may be some strange platform without it).
There are considerably less strange platforms that have per-user
disk quotas.
Hello,
Thank you for pointing that. It is one crucial point of this
patch. Sorry for not mentioning on the point.
At Sun, 6 Sep 2015 09:24:48 +0100, Simon Riggs wrote in
> > Tomas Vondra is now working on heavily-equipped multivariate
> > statistics for OLAP usage. In contrast, this is a light
Hello,
> FWIW Horiguchi-san is one of the few people who actually took time to
> review
I personally think such kind of things should not to be counted
in judging this issue:)
> the multivariate stats patch, and I don't quite see this patch
> as conflicting with the multivariate one.
>
> It imp
On 9/6/15 3:34 PM, Joe Conway wrote:
> On 09/02/2015 02:54 PM, Alvaro Herrera wrote:
>> Josh Berkus wrote:
>>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote:
I think trying to duplicate the exact strings isn't too nice an
interface.
>>>
>>> Well, for pg_controldata, no, but what else would
Hello,
> > 5) syntax
> > -
> > The syntax might be one of the pain points if we eventually decide to
> commit the multivariate stats patch. I have no intention in blocking this
> patch for that reasons, but if we might design the syntax to make it
> compatible with the multivariate patch,
On Sun, Sep 6, 2015 at 5:58 PM, Andres Freund wrote:
>
> On 2015-09-04 23:44:21 +0100, Simon Riggs wrote:
> > I see the need for both current wait information and for cumulative
> > historical detail.
> >
> > I'm willing to wait before reviewing this, but not for more than 1 more
CF.
> >
> > Andre
On Tue, Aug 04, 2015 at 02:21:16PM +0900, Michael Paquier wrote:
> >> On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg wrote:
> >> > for something between 10% and 20% of the devel builds for
> >> > apt.postgresql.org
> >> > (which happen every 6h if there's a git change, so it happens every few
>
On Sat, Jul 11, 2015 at 10:05 AM, Peter Geoghegan wrote:
> Currently, there are certain aggregates that sort some tuples before
> making a second pass over their memtuples array (through the tuplesort
> "gettuple" interface), calling one or more attribute equality operator
> functions as they go.
On Mon, Sep 7, 2015 at 1:16 PM, Noah Misch wrote:
> On Tue, Aug 04, 2015 at 02:21:16PM +0900, Michael Paquier wrote:
>> >> On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg wrote:
>> >> > for something between 10% and 20% of the devel builds for
>> >> > apt.postgresql.org
>> >> > (which happen eve
On Mon, Sep 7, 2015 at 3:09 AM, Andres Freund wrote:
>
> On 2015-09-06 16:05:01 +0200, Fabien COELHO wrote:
> > >Wouldn't it be just as easy to put this logic into the checkpointing
code?
> >
> > Not sure it would simplify anything, because the checkpointer currently
> > knows about buffers but fl
On Sat, Sep 5, 2015 at 4:22 AM, Ozgun Erdogan wrote:
> Hey Robert,
>
> Now the question is, where should the code that does all of this live?
>> postgres_fdw? Some new, sharding-specific FDW? In core? I don't
>> know for sure, but what I do know is that we could make a lot of
>> progress over
51 matches
Mail list logo
