Congrats everyone and special congratulations to Amit for becoming the
first Indian PostgreSQL committer !!
On Sat, Jun 2, 2018 at 9:40 AM, Nikolay Samokhvalov
wrote:
> сб, 2 июня 2018 г. в 1:10, Teodor Sigaev :
>
>>
>> > Etsuro Fujita
>> > Peter Geoghegan
>> > Amit Kapila
>> > Alexander Korotko
сб, 2 июня 2018 г. в 1:10, Teodor Sigaev :
>
> > Etsuro Fujita
> > Peter Geoghegan
> > Amit Kapila
> > Alexander Korotkov
> > Thomas Munro
> > Michael Paquier
> > Tomas Vondra
> >
> > Congratulations to all!
>
> +7!
+7,
and +2 to you and Oleg with progress in building your Postgres team
Nikola
On Fri, Jun 01, 2018 at 05:05:11PM -0400, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
Congratulations to all.
On Sat, 2 Jun 2018, 08:20 Kuntal Ghosh, wrote:
> Congratulations all.
>
> On Sat, 2 Jun 2018 at 2:35 AM, Tom Lane wrote:
>
>> The core team is pleased to announce the appointment of seven
>> new Postgres committers:
>>
>> Etsuro Fujita
>> Peter Geoghegan
>> Amit Kapila
>
Congratulations all.
On Sat, 2 Jun 2018 at 2:35 AM, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulation
Great honour. Congratulations to all.
On Sat, 2 Jun 2018, 02:35 Tom Lane, wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> C
On Fri, Jun 1, 2018 at 5:05 PM, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
Congratulat
On Fri, Jun 1, 2018 at 5:05 PM, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
>
Congratul
Charles Cui writes:
>I have a new type defined like this
> CREATE TYPE thrift_binary (
> INPUT = thrift_binary_in,
> OUTPUT = thrift_binary_out,
> LIKE = bytea
> );
> in thrift_binary_in, it accepts cstring and returns thrift_binary.
OK, that's what it should do.
> And in
> this
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
Conjurations!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English:
On 1 June 2018 at 17:05, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
>
>
Hi mentors and hackers,
I have a new type defined like this
CREATE TYPE thrift_binary (
INPUT = thrift_binary_in,
OUTPUT = thrift_binary_out,
LIKE = bytea
);
in thrift_binary_in, it accepts cstring and returns thrift_binary. And in
this function I returned a bytea because the create
El vie., 1 de jun. de 2018 4:05 PM, Tom Lane escribió:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
Gr
On Sat, Jun 2, 2018 at 2:35 AM, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
>
>
Thank y
Thanks!
Congratulations to the other 6 new committers.
--
Peter Geoghegan
(Sent from my phone)
Le 1 juin 2018 23:54:28 GMT+02:00, Julien Rouhaud a écrit :
>On Fri, Jun 1, 2018 at 11:22 PM, Joe Conway wrote:
>> On 06/01/2018 05:14 PM, Andres Freund wrote:
>>> On 2018-06-01 17:05:11 -0400, Tom Lane wrote:
The core team is pleased to announce the appointment of seven
new Postgres co
Etsuro Fujita
Peter Geoghegan
Amit Kapila
Alexander Korotkov
Thomas Munro
Michael Paquier
Tomas Vondra
Congratulations to all!
+7!
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
> On Jun 1, 2018, at 5:22 PM, Joe Conway wrote:
>
>> On 06/01/2018 05:14 PM, Andres Freund wrote:
>>> On 2018-06-01 17:05:11 -0400, Tom Lane wrote:
>>> The core team is pleased to announce the appointment of seven
>>> new Postgres committers:
>>>
>>> Etsuro Fujita
>>> Peter Geoghegan
>>> Am
On 2018-Jun-01, Jonathan S. Katz wrote:
> This would also coincide well with the content we want to move from
> the wiki to www.
What content is that?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jun 1, 2018 at 11:22 PM, Joe Conway wrote:
> On 06/01/2018 05:14 PM, Andres Freund wrote:
>> On 2018-06-01 17:05:11 -0400, Tom Lane wrote:
>>> The core team is pleased to announce the appointment of seven
>>> new Postgres committers:
>>>
>>> Etsuro Fujita
>>> Peter Geoghegan
>>> Amit Kapil
On Sat, Jun 2, 2018 at 12:05 AM Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
>
Thank yo
On Fri, Jun 01, 2018 at 03:00:10PM -0400, Alvaro Herrera wrote:
> On 2018-May-23, Justin Pryzby wrote:
>
> > There's two other, wider changes to consider:
...
>
> > - should we find a unified term for "inheritence-based partitioning" and
> > avoid
> >using the word "partitioning" in that co
> On Jun 1, 2018, at 5:05 PM, Tom Lane wrote:
>
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
>
>
On 06/01/2018 05:14 PM, Andres Freund wrote:
> On 2018-06-01 17:05:11 -0400, Tom Lane wrote:
>> The core team is pleased to announce the appointment of seven
>> new Postgres committers:
>>
>> Etsuro Fujita
>> Peter Geoghegan
>> Amit Kapila
>> Alexander Korotkov
>> Thomas Munro
>> Michael Paquier
>>
On 2018-06-01 17:05:11 -0400, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
+1!
- Andre
On Fri, Jun 1, 2018 at 5:05 PM, Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
> Congratulations to all!
>
>
On Fri, Jun 1, 2018 at 6:05 PM, Tom Lane wrote:
>
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
Great news!! Congrats to everyone!!
The core team is pleased to announce the appointment of seven
new Postgres committers:
Etsuro Fujita
Peter Geoghegan
Amit Kapila
Alexander Korotkov
Thomas Munro
Michael Paquier
Tomas Vondra
Congratulations to all!
regards, tom lane
> On May 29, 2018, at 11:55 AM, Tatsuo Ishii wrote:
>
>>>A lot of people contribute in communities via github these days. We
>>>should add a CONTRIBUTING.md that explains how to do so, given that we
>>>don't use github. That's shown automatically when doing a pull requests
>>>et
On Fri, Jun 01, 2018 at 02:53:09PM -0400, Michael Paquier wrote:
> Definitely, while the previous patch was around mainly to show where
> things are incorrect, I am attaching a set of patches for HEAD which can
> be used for commit:
> - One patch which addresses the several lock problems and adds s
On 2018-May-23, Justin Pryzby wrote:
> There's two other, wider changes to consider:
>
> - should "5.10.4. Partition Pruning" be moved after "5.10.2. Declarative
>Partitioning", rather than after "5.10.3. Implementation Using
> Inheritance" ?
I considered that when reorganizing this sectio
Pushed. I made a couple of minor changes, in particular I added the
word "one" to this sentence, which was already under discussion:
On 2018-May-24, Justin Pryzby wrote:
> On Thu, May 24, 2018 at 11:30:40AM +0900, Amit Langote wrote:
> > +possible to show the difference between a plan who
On Fri, Jun 01, 2018 at 07:32:26PM +0200, Magnus Hagander wrote:
> Basically, this method *is* safe as long as you have proper storage. For
> example, if yo have a RAID controller with cache, it is perfectly safe. If
> you have a consumer level device with unsafe caching, then it's not safe.
> This
On Thu, May 31, 2018 at 06:31:24PM +0100, Simon Riggs wrote:
Thanks for the input, Simon. I have been able to spend more time
monitoring the slot-related code.
> On 28 May 2018 at 09:57, Michael Paquier wrote:
>> Yes, this only returns InvalidXLogRecPtr if the location could not be
>> moved for
Le 30/05/2018 à 03:57, David Rowley a écrit :
> On 26 May 2018 at 09:17, Tom Lane wrote:
>> I'm inclined to think that we should flush find_appinfos_by_relids
>> altogether, along with these inefficient intermediate arrays, and instead
>> have the relevant places in adjust_appendrel_attrs call
On Fri, Jun 1, 2018 at 8:18 PM, Laurenz Albe
wrote:
> Amit Kapila wrote:
> > On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
> wrote:
> > > I recently read our documentation about reliability on Windows:
> > >
> > > > On Windows, if wal_sync_method is open_datasync (the default), write
> caching ca
On Fri, Jun 1, 2018 at 3:26 PM, Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
> wrote:
>
>> I recently read our documentation about reliability on Windows:
>>
>> > On Windows, if wal_sync_method is open_datasync (the default), write
>> caching can
>> > be disabled by unchecki
True… but in that case it needs to be more expressive.
i.e.
with d as (
select date
from inventory
order by date
limit 10
), df as (
select distinct date
from d
)
select i.date, a.name, i.quantity
from inventory i
join asset a on a.id = i.id_asset
where i.date in (select date from df)
Hi Rui,
Unfortunately sorting and limiting the CTE doesn't work properly, because
exactly which 100 rows are selected depends on values in the asset table, which
are not known at the time that the cte is evaluated.
I can work around it for our case by querying for the unique dates that make it
2018-06-01 18:36 GMT+02:00 Euler Taveira :
> 2018-06-01 9:00 GMT-03:00 Michael Paquier :
> > On Thu, May 31, 2018 at 10:59:04PM -0400, Robert Haas wrote:
> >> On Wed, May 30, 2018 at 2:00 PM, Michael Paquier
> wrote:
> >>> Hm. There could be an argument for improving the user experience here
> >
2018-06-01 9:00 GMT-03:00 Michael Paquier :
> On Thu, May 31, 2018 at 10:59:04PM -0400, Robert Haas wrote:
>> On Wed, May 30, 2018 at 2:00 PM, Michael Paquier wrote:
>>> Hm. There could be an argument for improving the user experience here
>>> so as some cleanup is at least attempted except if --
On Wed, May 30, 2018 at 9:26 PM Robert Haas wrote:
> The FDW approach, of which I have been a supporter for some years now,
> is really aiming at a different target, which is to allow efficient
> analytics queries across a multi-node cluster. I think we're getting
> pretty close to being able to
2018-06-01 17:53 GMT+02:00 Tom Lane :
> Ashutosh Bapat writes:
> > I think the patch is right if we were to handle only SQLValueFunction,
> > but the bigger picture here is that we aren't evaluating stable
> > functions before run-time partition pruning happens. I was under the
> > impression tha
On Fri, Jun 1, 2018 at 11:27 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> In order to avoid double parsing, we might want to find a way to pass
>> a "normalized" parse tree down to the foreign server. We need to
>> normalize the OIDs in the parse tree since those may be different
>> across the
On Fri, Jun 1, 2018 at 11:10 AM, Simon Riggs wrote:
>
> Using a central coordinator also allows multi-node transaction
> control, global deadlock detection etc..
But that becomes an SPOF and then we have to configure a standby for
that. I am not saying that that's a bad design but it's not very g
Ashutosh Bapat writes:
> I think the patch is right if we were to handle only SQLValueFunction,
> but the bigger picture here is that we aren't evaluating stable
> functions before run-time partition pruning happens. I was under the
> impression that the stable functions/expressions get evaluated
In the meantime you can force it with CTE.
with inv as (
select id_asset
, inventory.date
, quantity
from inventory
order by inventory.date
limit 100
)
select inv.date, asset.name, inv.quantity
from inv
join asset on id_asset = asset.id
order by inv.date, asset.name
;
> On Jun 1,
On Fri, Jun 1, 2018 at 9:47 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 1 June 2018 at 07:19, Pavel Stehule wrote:
>>
>> Partition pruning is working now.
>>
>> Is it expected? Tested on fresh master.
>
> That's interesting. So there are two cases:
>
> * vlozeno > (select current_date)
Ashutosh Bapat writes:
> In order to avoid double parsing, we might want to find a way to pass
> a "normalized" parse tree down to the foreign server. We need to
> normalize the OIDs in the parse tree since those may be different
> across the nodes.
I don't think this is a good idea at all. It b
2018-06-01 17:15 GMT+02:00 Ashutosh Bapat :
> On Fri, Jun 1, 2018 at 12:56 AM, Pavel Stehule
> wrote:
> > Hi
> >
> > postgres=# SELECT count(*) from data;
> > ┌─┐
> > │ count │
> > ╞═╡
> > │ 100 │
> > └─┘
> > (1 row)
> >
> > \dt+ can display actual size of partitione
On Fri, Jun 1, 2018 at 12:56 AM, Pavel Stehule wrote:
> Hi
>
> postgres=# SELECT count(*) from data;
> ┌─┐
> │ count │
> ╞═╡
> │ 100 │
> └─┘
> (1 row)
>
> \dt+ can display actual size of partitioned table data - now zero is
> displayed
>
> postgres=# \dt+ data
>
It does indeed!
QUERY PLAN
Limit (cost=398.50..398.50 rows=10
On 1 June 2018 at 04:00, MauMau wrote:
> The SQL processor should be one layer, not two layers.
For OLTP, that would be best. But it would be restricted to
single-node requests, leaving you the problem of how you know ahead of
time whether an SQL statement was single node or not.
Using a centra
On 1 June 2018 at 15:44, Ashutosh Bapat wrote:
> On Thu, May 31, 2018 at 11:00 PM, MauMau wrote:
>> 2018-05-31 22:44 GMT+09:00, Robert Haas :
>>> On Thu, May 31, 2018 at 8:12 AM, MauMau wrote:
Oh, I didn't know you support FDW approach mainly for analytics. I
guessed the first target
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe wrote:
> > I recently read our documentation about reliability on Windows:
> >
> > > On Windows, if wal_sync_method is open_datasync (the default), write
> > > caching can
> > > be disabled by unchecking
> > > My Computer\Open\dis
On Thu, May 31, 2018 at 11:00 PM, MauMau wrote:
> 2018-05-31 22:44 GMT+09:00, Robert Haas :
>> On Thu, May 31, 2018 at 8:12 AM, MauMau wrote:
>>> Oh, I didn't know you support FDW approach mainly for analytics. I
>>> guessed the first target was OLTP read-write scalability.
>>
>> That seems like
Hi, James!
On Thu, May 31, 2018 at 11:10 PM James Coleman wrote:
> I've attached an updated copy of the patch that applies cleanly to
> current master.
>
Thank you for rebasing this patch. Next time sending a patch, please make
sure you've bumped
its version, if even you made no changes there
On Fri, Jun 1, 2018 at 7:43 AM, Kyotaro HORIGUCHI
wrote:
> On Thu, May 31, 2018 at 11:34 AM, Ashutosh Bapat
> wrote:
>> On Thu, May 31, 2018 at 7:36 PM, Tom Lane wrote:
>>> What you want for the first part of that is basically like
>>> generate_new_param() in subselect.c. We don't expose that p
> On 1 June 2018 at 07:19, Pavel Stehule wrote:
>
> Partition pruning is working now.
>
> Is it expected? Tested on fresh master.
That's interesting. So there are two cases:
* vlozeno > (select current_date) (pruning works)
* vlozeno > current_date (pruning doesn't work)
In pull_partkey_params
On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
wrote:
> I recently read our documentation about reliability on Windows:
>
> > On Windows, if wal_sync_method is open_datasync (the default), write
> caching can
> > be disabled by unchecking
> > My Computer\Open\disk drive\Properties\Hardware\Properti
The incremental sort patch seems to significantly improve performance for
your query: https://commitfest.postgresql.org/17/1124/
On Fri, Jun 1, 2018 at 7:46 AM, Christopher Wilson <
chris.wil...@cantabcapital.com> wrote:
> Dear Postgres developers,
>
>
>
> I sent this query to the performance lis
On Fri, Jun 01, 2018 at 11:43:33AM +0200, Laurenz Albe wrote:
> I am worried that there might be loads of Windows installations out there
> happily
> running productive databases with an unsafe setup, so I'd even suggest
> backpatching
> such a change.
This is not only your imagination, there ar
On Thu, May 31, 2018 at 10:59:04PM -0400, Robert Haas wrote:
> On Wed, May 30, 2018 at 2:00 PM, Michael Paquier wrote:
>> Hm. There could be an argument for improving the user experience here
>> so as some cleanup is at least attempted except if --no-clean is defined
>> by the caller when --creat
Dear Postgres developers,
I sent this query to the performance list a couple of days ago, but nobody has
come up with any suggestions. I was wondering if you'd like to consider it?
If this is interesting but nobody has time to implement it, then I would
potentially be willing to implement and s
On Thu, May 31, 2018 at 11:34 AM, Ashutosh Bapat
wrote:
> On Thu, May 31, 2018 at 7:36 PM, Tom Lane wrote:
>> What you want for the first part of that is basically like
>> generate_new_param() in subselect.c. We don't expose that publicly
>> at the moment, but we could, or maybe better to invent
I recently read our documentation about reliability on Windows:
> On Windows, if wal_sync_method is open_datasync (the default), write caching
> can
> be disabled by unchecking
> My Computer\Open\disk drive\Properties\Hardware\Properties\Policies\Enable
> write caching
> on the disk. Alternative
Hi Tom,
We are using Python 2.7.12 , built on AIX 6.1 with GCC .
Looking at its build log, I see about the traces of the configure:
64bit: checking whether to enable large file support... no
32bit: checking whether to enable large file support... yes
/home2/freeware/include/python2.7/pyconfig-p
Hi Tom,
Here are information about the Perl version we are using on our AIX 7.2 machine.
However, as I said already, all PostgreSQL tests of v10.4 and 9.6.9 are OK,
both 32 and 64bit.
# rpm -qa | grep perl
perl-5.24.0-3
This version 5.24.0 release 3 of Perl has been built on a AIX 6.1 machin
68 matches
Mail list logo
