On Fri, May 25, 2018 at 3:37 PM, Andres Freund wrote:
> Hi,
>
> Moving discussion to -hackers. Tom, I think you worked most with this
> code, your input would be appreciated.
>
> Original discussion is around:
> http://archives.postgresql.org/message-id/20180524211311.
> tnswfnjwnii54htx%40alvhe
On 06/19/2018 02:33 PM, Konstantin Knizhnik wrote:
On 19.06.2018 14:03, Tomas Vondra wrote:
On 06/19/2018 11:08 AM, Konstantin Knizhnik wrote:
...
>>>
Also there are two points which makes prefetching into shared buffers
more complex:
1. Need to spawn multiple workers to make prefetch in p
(2018/06/15 20:56), Etsuro Fujita wrote:
Actually, I've
created a patch implementing that proposal.
But I think that patch needs more work, so I'm
planning to post it next week.
Here is a patch for that.
* As I said upthread, the patch makes code much more simple; I removed
all the changes
On 19.06.2018 14:03, Tomas Vondra wrote:
On 06/19/2018 11:08 AM, Konstantin Knizhnik wrote:
On 18.06.2018 23:47, Andres Freund wrote:
On 2018-06-18 16:44:09 -0400, Robert Haas wrote:
On Sat, Jun 16, 2018 at 3:41 PM, Andres Freund
wrote:
The posix_fadvise approach is not perfect, no dou
On Tue, Jun 19, 2018 at 4:41 PM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> It's already in the commitfest, although I think it's almost certain to be
> pushed out to the September CF. I'll add this email to the existing item.
>
>
Thanks Andrew; I was gonna do that once the emai
On 06/19/2018 07:06 AM, Pavan Deolasee wrote:
Hello,
I would like to resubmit the MERGE patch for PG12. The past
discussions about the patch can be found here [1] [2].
The patch is rebased on the current master. But otherwise I haven't
done any further work on it since it was punted from
On 06/19/2018 11:08 AM, Konstantin Knizhnik wrote:
On 18.06.2018 23:47, Andres Freund wrote:
On 2018-06-18 16:44:09 -0400, Robert Haas wrote:
On Sat, Jun 16, 2018 at 3:41 PM, Andres Freund
wrote:
The posix_fadvise approach is not perfect, no doubt about that. But it
works pretty well for
On Mon, Jun 18, 2018 at 10:33 PM, Peter Geoghegan wrote:
> On Mon, Jun 18, 2018 at 7:57 AM, Claudio Freire
> wrote:
>> Way back when I was dabbling in this kind of endeavor, my main idea to
>> counteract that, and possibly improve performance overall, was a
>> microvacuum kind of thing that woul
On Tue, Jun 19, 2018 at 4:22 PM, Michael Paquier wrote:
>
> I was under the impression that this was implied in the precious
> phrasing but you guys visibly don't match with my impression. So I
> would suggest this paragraph at the end:
> "Mixing temporary and permanent relations in the same part
On Tue, Jun 19, 2018 at 02:50:44PM +0530, Ashutosh Bapat wrote:
> +
> +
> +
> + Mixing temporary and permanent relations in the same partition tree
> + is not allowed. Hence, if the root partitioned table is permanent,
>
> Do we want to mention "root" explicitly here?
Yes,
On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
wrote:
> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
> wrote:
> >>
> >> > I'm not sure it is usefull in release notes since it is more about API,
> >> > and not
> >> > user-facing change. Just in case.
> >> > GiST opclasses n
Hi all,
I just read an article about a recent architecture change in newer Intel
processors.
As mentioned in
[1]
https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpus-are-sometimes-50-slower-how-intel-has-broken-existing-code/
Intel changed the latency respective reciproque throug
> On 18 June 2018 at 19:31, Alexander Korotkov
> wrote:
>>
>> A couple of questions to begin with.
>>
>> Should the patch continue to "piggy-back" on T_IndexOnlyScan, or should
>> a new node (T_IndexSkipScan) be created ? If latter, then there likely
>> will be functionality that needs to be refa
On Tue, Jun 19, 2018 at 8:05 AM, Peter Geoghegan wrote:
> On Mon, Jun 18, 2018 at 2:54 PM, Peter Geoghegan wrote:
>> On Sun, Jun 17, 2018 at 9:39 PM, Andrey V. Lepikhov
>> wrote:
>>> Patch '0001-retail-indextuple-deletion' introduce new function
>>> amtargetdelete() in access method interface. P
On Tue, Jun 19, 2018 at 5:43 PM, Alexander Korotkov
wrote:
> On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada
> wrote:
>> On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov
>> > So, I'm proposing to raise maximum valus of
>> > vacuum_cleanup_index_scale_factor to DBL_MAX. Any objections?
>> >
On 19.06.2018 01:11, Andres Freund wrote:
On 2018-06-18 18:05:11 -0400, Tom Lane wrote:
Andres Freund writes:
On 2018-06-18 17:57:04 -0400, Tom Lane wrote:
I think the actually desirable way to handle this sort of thing is through
an "index advisor" sort of plugin, which can hide a given i
On Tue, Jun 19, 2018 at 1:24 PM, Michael Paquier wrote:
> On Tue, Jun 19, 2018 at 04:27:08PM +0900, Amit Langote wrote:
>> Looking at what changed from my patch:
>>
>> -One cannot have both temporary and permanent relations in a given
>> -partition tree. That is, if the root partitioned t
On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
wrote:
>>
>> > I'm not sure it is usefull in release notes since it is more about API,
>> > and not
>> > user-facing change. Just in case.
>> > GiST opclasses now can omit compress and decompress functions. If compress
>> > function i
Hi Thomas
Thank you for your reply.
>This is not clear to me. ECPGfreeSQLDA() releases a whole chain, but
>free() only releases a single SQLDA(), so they are obviously not
>interchangeable. When exactly should a user prefer one over the other?
If an application use FETCH ALL to get the result
On 18.06.2018 23:47, Andres Freund wrote:
On 2018-06-18 16:44:09 -0400, Robert Haas wrote:
On Sat, Jun 16, 2018 at 3:41 PM, Andres Freund wrote:
The posix_fadvise approach is not perfect, no doubt about that. But it
works pretty well for bitmap heap scans, and it's about 13249x better
(roug
On 2018/06/19 17:51, Amit Langote wrote:
> On 2018/05/17 11:48, Amit Langote wrote:
>> On 2018/05/17 11:40, David Rowley wrote:
>>> On 17 May 2018 at 13:52, Amit Langote wrote:
Commit 499be013de6 used 'partition' where it really meant 'partitioned' in
a few places including in a variable
On 2018/05/17 11:48, Amit Langote wrote:
> On 2018/05/17 11:40, David Rowley wrote:
>> On 17 May 2018 at 13:52, Amit Langote wrote:
>>> Commit 499be013de6 used 'partition' where it really meant 'partitioned' in
>>> a few places including in a variable name. For example, what almost all
>>> places
On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada wrote:
> On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov
> > So, I'm proposing to raise maximum valus of
> > vacuum_cleanup_index_scale_factor to DBL_MAX. Any objections?
> >
>
> I agree to expand the maximum value. But if users don't want inde
On Mon, Jun 18, 2018 at 9:27 PM, Andres Freund wrote:
> On 2018-06-18 17:10:12 +0530, Jeevan Chalke wrote:
> > On Mon, Jun 18, 2018 at 5:02 PM, Rajkumar Raghuwanshi <
> > rajkumar.raghuwan...@enterprisedb.com> wrote:
> >
> > > Hi,
> > >
> > > Below test case crashed, when set enable_partitionwise
On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov
wrote:
> Hi!
>
> On Sat, Jun 16, 2018 at 11:23 PM Darafei "Komяpa" Praliaskouski
> wrote:
>> It is cool to see this in Postgres 11. However:
>>
>>>
>>> 4) vacuum_cleanup_index_scale_factor can be set either by GUC or reloption.
>>> Default value
In looking over pg_verify_checksums I found a few small things that I think
would improve on it:
* pg_verify_checksums was placed in the Client Utils section in the docs.
Since it requries physical access to the cluster datafiles it seems to belong
in the Server Utils section.
* The -D option and
Hi.
The description of DEFAULT in the documentation currently says:
"The value is any variable-free expression (subqueries and
cross-references to other columns in the current table are not allowed)."
But the value cannot be an aggregate expression, a window function, or a
set-returning function
On Tue, Jun 19, 2018 at 04:27:08PM +0900, Amit Langote wrote:
> Looking at what changed from my patch:
>
> -One cannot have both temporary and permanent relations in a given
> -partition tree. That is, if the root partitioned table is permanent,
> -so must be its partitions at all lev
On 18.06.2018 23:34, Robbie Harwood wrote:
t
Konstantin Knizhnik writes:
On 06.06.2018 02:03, Thomas Munro wrote:
On Wed, Jun 6, 2018 at 2:06 AM, Konstantin Knizhnik
wrote:
Thank you for review. Updated version of the patch fixing all reported
problems is attached.
Small problem on Win
Hi Nico,
I’m pretty impressed anything in this space can be written entirely in PlPGQSL!
If you did integrate your implementation, it would be easy for my Extension to
read from a table other than the one which it gets the MV definition from...
Although having said that, if you went down the ro
On Mon, Jun 18, 2018 at 6:19 PM, Amit Khandekar wrote:
> On 18 June 2018 at 17:56, Amit Kapila wrote:
>> On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar wrote:
>>> Should we also create a test case where we can verify that some
>>> unnecessary or duplicate triggers are not executed?
>>>
>>
>> I am
Thanks. Some review comments here.
+create table inh_perm_parent (a1 int);
+create temp table inh_temp_parent (a1 int);
+create temp table inh_temp_child (a1 int) inherits (inh_perm_parent); -- ok
+NOTICE: merging column "a1" with inherited definition
You could actually avoid this notice by chan
On 2018/06/19 14:47, Michael Paquier wrote:
> On Tue, Jun 19, 2018 at 10:56:49AM +0900, Amit Langote wrote:
>> On 2018/06/18 15:02, Michael Paquier wrote:
>>> Those tests should be upper-case I think to keep consistency with the
>>> surrounding code.
>>
>> As you may have seen in the changed code,
101 - 133 of 133 matches
Mail list logo
