Hello,
On 2015-08-30 PM 07:58, My Life wrote:
> Hi, everyone! I'd like to propose a postgres partition implementation.
> First, I would show the design to everyone, and talk about it. If we think
> the design is not very bad, and can be commit to the PostgreSQL baseline,
> then I will post the co
There is already a recent proposal on hackers about partition support in
PostgreSQL by Amit Langote. You will find the thread at
http://www.postgresql.org/message-id/55d3093c.5010...@lab.ntt.co.jp. May be
you can collaborate with the ongoing work.
On Sun, Aug 30, 2015 at 4:28 PM, My Life wrote:
On Sun, Aug 30, 2015 at 4:52 AM, Pavel Stehule
wrote:
> Hi
>
> I am starting to work review of this patch
>
> Hi Pavel,
Thanks for your review.
> 2015-07-13 9:54 GMT+02:00 dinesh kumar :
>
>> Hi All,
>>
>> Greetings for the day.
>>
>> Would like to discuss on below feature here.
>>
>> Feature:
>
>
> At PGCon we agreed to have such meeting in Vienna at least. But I think we
> should be prepared and try to clean all our issues before. It looks like we
> already out of time,but probably we could meet in Hong Kong ?
>
> Honestly, I still don't know which approach is better, we already played
On Sun, Aug 30, 2015 at 7:47 AM, Bruce Momjian wrote:
>
> I have recently increased my public statements about the idea of adding
> horizontal scaling/sharding to Postgres. I wanted to share with hackers
> a timeline of how we got here, and where I think we are going in the
> short term:
>
> 2012-
2015-08-30 10:34 GMT+02:00 Pavel Stehule :
>
>
> 2015-08-30 10:30 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>> On Aug 29, 2015 7:31 PM, "Pavel Stehule" wrote:
>> >
>> >
>> >
>> > 2015-08-29 18:36 GMT+02:00 Andres Freund :
>> >>
>> >> On 2015-08-29 18:27:59 +0200, Pavel Ste
On Mon, Aug 24, 2015 at 12:45 PM, Fabien COELHO wrote:
>
>
> Also check the file:
>
> sh> file ./avg.py
> ./avg.py: Python script, UTF-8 Unicode text executable
>
There were some CRLF line terminators, after removing those, it worked
fine and here are the results of some of the tests done for
On Mon, Aug 31, 2015 at 11:48 AM, Bruce Momjian wrote:
> On Sun, Aug 30, 2015 at 10:08:06PM -0400, Bruce Momjian wrote:
>> On Mon, Aug 31, 2015 at 09:53:57AM +0900, Michael Paquier wrote:
>> > Well, I have had many such discussions with XC/XL folks, and that was
>> > my
>> > opinion. I h
On Mon, Aug 31, 2015 at 11:08 AM, Bruce Momjian wrote:
>
> On Mon, Aug 31, 2015 at 09:53:57AM +0900, Michael Paquier wrote:
> > Well, I have had many such discussions with XC/XL folks, and that was my
> > opinion. I have seen almost no public discussion about this because the
> > idea
On Sun, Aug 30, 2015 at 10:08:06PM -0400, Bruce Momjian wrote:
> On Mon, Aug 31, 2015 at 09:53:57AM +0900, Michael Paquier wrote:
> > Well, I have had many such discussions with XC/XL folks, and that was my
> > opinion. I have seen almost no public discussion about this because the
> >
On Mon, Aug 31, 2015 at 09:53:57AM +0900, Michael Paquier wrote:
> Well, I have had many such discussions with XC/XL folks, and that was my
> opinion. I have seen almost no public discussion about this because the
> idea had almost no chance of success. If it was possible, someone wou
Hi, everyone! I'd like to propose a postgres partition implementation. First, I
would show the design to everyone, and talk about it. If we think the design is
not very bad, and can be commit to the PostgreSQL baseline, then I will post
the code to the community.
(note: my english is not very go
Hi, everyone! I'd like to propose a postgres partition implementation. First, I
would show the design to everyone, and talk about it. If we think the design is
not very bad, and can be commit to the PostgreSQL baseline, then I will post
the code to the community.
(note: my english is not very go
On Mon, Aug 31, 2015 at 7:29 AM, Bruce Momjian wrote:
> On Sun, Aug 30, 2015 at 03:31:10PM +0100, Simon Riggs wrote:
> > I realized that we would never get community acceptance to dump the
> XC
> > (or XL) code needed for sharding into community Postgres
> >
> >
> > How or why did you rea
Tatsuo Ishii writes:
> Notice that JDBC driver sends Parse, Bind and Execute without Sync
> followed then immediately sends another Parse message.
> I wonder if this violates our extended query protocol.
It does not.
> "At completion of each series of extended-query messages, the frontend
> sho
I wrote:
> I came across some websites suggesting that icc will handle gcc-style
> asm blocks as long as you give it the -fasm-blocks command line option.
> It would be awfully nice to get rid of the __INTEL_COMPILER special
> cases in s_lock.h and the atomics headers --- would someone who has
> ic
On Sun, Aug 30, 2015 at 10:36:23PM +0300, Oleg Bartunov wrote:
> Honestly, I still don't know which approach is better, we already played with
> XL (ported to 9.4) and identified some very strong issues with inconsistency,
> which scared us, especially taking into account how easy we found them. X
While playing with Java application using JDBC driver, I noticed
an interesting fact:
When autocommit is off, JDBC driver issues following messages:
20:10:54.731 (2) FE=> Parse(stmt=S_1,query="BEGIN",oids={})
20:10:54.731 (2) FE=> Bind(stmt=S_1,portal=null)
20:10:54.731 (2) FE=> Execute(portal
Jeff Janes writes:
> On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
>> Your earlier point about how the current design throttles insertions to
>> keep the pending list from growing without bound seems like a bigger deal
>> to worry about. I think we'd like to have some substitute for that.
>>
On Mon, Aug 31, 2015 at 8:42 AM, Tom Lane wrote:
> A useful comparison point is the testing Greg Stark did recently for VAX.
> Certainly no-one's ever again going to try to get useful work done with
> Postgres on a VAX, but that still taught us some good things about
> unnecessary IEEE-floating-p
I came across some websites suggesting that icc will handle gcc-style
asm blocks as long as you give it the -fasm-blocks command line option.
It would be awfully nice to get rid of the __INTEL_COMPILER special
cases in s_lock.h and the atomics headers --- would someone who has
icc at hand check int
On Sun, Aug 30, 2015 at 03:31:10PM +0100, Simon Riggs wrote:
> On 30 August 2015 at 03:17, Bruce Momjian wrote:
>
> I have recently increased my public statements about the idea of adding
> horizontal scaling/sharding to Postgres.
>
> Glad to see it. Many people have been pushing such thi
On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
> Jeff Janes writes:
>
> Your earlier point about how the current design throttles insertions to
> keep the pending list from growing without bound seems like a bigger deal
> to worry about. I think we'd like to have some substitute for that.
>
On Sat, Aug 29, 2015 at 12:48:23AM +0200, Daniel Verite wrote:
> Hi,
>
> This is a reboot of my previous proposal for pivoting results in psql,
> with a new patch that generalizes the idea further through a command
> now named \rotate, and some examples.
Neat!
Thanks for putting this together :
David Fetter writes:
> At a minimum, we should de-support every platform on which literally
> no new deployments will ever happen.
> I'm looking specifically at you, HPUX, and I could make a pretty good
> case for the idea that we can relegate 32-bit platforms to the ash
> heap of history, at leas
Re: Tom Lane 2015-08-30 <20976.1440946...@sss.pgh.pa.us>
> Christoph Berg writes:
> > postgres =# set timezone = 'Etc/UTC+1';
> > SET
> > postgres =# set datestyle = 'postgres';
> > SET
> > postgres =# select '2015-01-01 01:00:00 +0100'::timestamptz;
> > Wed 31 Dec 23:00:00 2014 ETC/UTC
>
> > po
Andres Freund writes:
> On 2015-08-30 15:28:42 -0400, Tom Lane wrote:
>> No no no, I'm proposing to remove the above-quoted lines and the configure
>> test. sig_atomic_t is required by C89; there is no reason anymore to
>> cope with it not being provided by .
> Ok, that works for me. You seemed
Andres Freund writes:
> On 2015-08-30 14:59:41 -0400, Tom Lane wrote:
>> HAVE_SIG_ATOMIC_T is a debatable case, in that the only thing we're
>> doing with it is c.h's
>>
>> /* sig_atomic_t is required by ANSI C, but may be missing on old platforms */
>> #ifndef HAVE_SIG_ATOMIC_T
>> typedef int si
On 2015-08-30 15:28:42 -0400, Tom Lane wrote:
> No no no, I'm proposing to remove the above-quoted lines and the configure
> test. sig_atomic_t is required by C89; there is no reason anymore to
> cope with it not being provided by .
Ok, that works for me. You seemed to be a bit more doubtful abou
On Sun, Aug 30, 2015 at 5:31 PM, Simon Riggs wrote:
> On 30 August 2015 at 03:17, Bruce Momjian wrote:
>
>> I have recently increased my public statements about the idea of adding
>> horizontal scaling/sharding to Postgres.
>
>
> Glad to see it. Many people have been pushing such things for year
Hi,
On 2015-08-30 14:59:41 -0400, Tom Lane wrote:
> 1. No buildfarm member in the available history (going back to 2012-01-01)
> has ever reported not having the POSIX signal interface, nor sig_atomic_t.
> (We don't run the POSIX-signals check on Windows systems, though.)
We, afaik, don't use any
A question in another project's mailing list prompted me to investigate
whether our support for non-POSIX signals is actually still of any value.
I grepped through the buildfarm server's configure-stage reports, and
found that:
1. No buildfarm member in the available history (going back to 2012-01
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/28/2015 07:21 PM, Adam Brightwell wrote:
> On 08/28/2015 08:37 AM, Joe Conway wrote:
>> So given all that, here is what I propose we do:
>>
>> 1.) Commit Kouhei's patch against HEAD and 9.5 (Joe) 2.) Commit
>> my modified patch against 9.4 and 9
Jeff Janes writes:
> Attached is a patch to deal with this without the heavyweight locks.
> I realized that using the clean up lock on the meta page, rather than the
> pending head page, would be easier to implement as a pin was already held
> on the meta page throughout, and the pending head page
On Sat, Aug 22, 2015 at 11:25 AM, Jeff Janes wrote:
> On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas
> wrote:
>
>> On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes wrote:
>> > User backends attempt to take the lock conditionally, because otherwise
>> they
>> > would cause an autovacuum already holding
Kevin Grittner writes:
> Tom Lane wrote:
>> Just out of curiosity --- what's the rationale for flushing after
>> every line, rather than once at the end of the loop?
> Isn't the loop over file handles written to?
Oh... I just automatically read it as looping over some data,
not printing the sam
Tom Lane wrote:
> Just out of curiosity --- what's the rationale for flushing after
> every line, rather than once at the end of the loop? Is there
> actual input-reading going on underneath the @$self notation?
> If it's just dumping data from process memory, I should think
> one flush would be
On 2015-08-30 11:33:28 -0400, Stephen Frost wrote:
> Yeah, I'm not really thrilled with all of this information being
> available to everyone on the system. We already get ding'd by people
> for not limiting who can see what connections there are to the database
> and this is doubling-down on that
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote:
>
> > I know I am coming in late here, but I know Heroku uses random user
> > names to allow a cluster to have per-user databases without showing
> > external user name details:
> > [...]
>
Alvaro Herrera writes:
> I imagine that esoteric platforms are not going to have cmake at all and
> are going to need their own installation anyway. Not sure if that's
> going to be more onerous than the requirement to install GNU make.
If we get to the point where this is starting to look like
Kevin Grittner writes:
> I find the TestLib.pm framework to be more friendly with the
> attached tweak to SimpleTee.pm. It's not a big deal, so if anyone
> objects I'll let it drop, and I don't think it merits anything
> fancier.
Just out of curiosity --- what's the rationale for flushing after
I find the TestLib.pm framework to be more friendly with the
attached tweak to SimpleTee.pm. It's not a big deal, so if anyone
objects I'll let it drop, and I don't think it merits anything
fancier.
Objections?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Christoph Berg writes:
> postgres =# set timezone = 'Etc/UTC+1';
> SET
> postgres =# set datestyle = 'postgres';
> SET
> postgres =# select '2015-01-01 01:00:00 +0100'::timestamptz;
> Wed 31 Dec 23:00:00 2014 ETC/UTC
> postgres =# select 'Wed 31 Dec 23:00:00 2014 ETC/UTC'::timestamptz;
> Wed 31
On 30 August 2015 at 03:17, Bruce Momjian wrote:
> I have recently increased my public statements about the idea of adding
> horizontal scaling/sharding to Postgres.
Glad to see it. Many people have been pushing such things for years, so it
is good to finally see some debate about this on Hacke
On Wed, Aug 26, 2015 at 4:59 PM, Michael Paquier
wrote:
> 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.
> >> Reviewer
Re: Michael Cree 2015-08-26 <20150826052530.GA4256@tower>
> I reported the failure to build on Alpha, with an explanation and a
> patch to fix it, to the Debian package maintainers over a year ago,
> and within about of a month of version 9.4 being uploaded to Debian.
>
> My recollection is that p
Discovered when debugging libpqtypes test failures:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795729
postgres =# set timezone = 'Etc/UTC+1';
SET
postgres =# set datestyle = 'postgres';
SET
postgres =# select '2015-01-01 01:00:00 +0100'::timestamptz;
Wed 31 Dec 23:00:00 2014 ETC/UTC
post
2015-08-30 10:30 GMT+02:00 Shulgin, Oleksandr
:
> On Aug 29, 2015 7:31 PM, "Pavel Stehule" wrote:
> >
> >
> >
> > 2015-08-29 18:36 GMT+02:00 Andres Freund :
> >>
> >> On 2015-08-29 18:27:59 +0200, Pavel Stehule wrote:
> >> > 2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zal
On Aug 29, 2015 7:31 PM, "Pavel Stehule" wrote:
>
>
>
> 2015-08-29 18:36 GMT+02:00 Andres Freund :
>>
>> On 2015-08-29 18:27:59 +0200, Pavel Stehule wrote:
>> > 2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr <
oleksandr.shul...@zalando.de>
>> > > Good point. There's still hope to set a flag and pr
49 matches
Mail list logo
