> "Tom" == Tom Lane writes:
Tom> However, it seems like it should still be on the table to look at
Tom> other code that just does sprintf's job faster (such as the stb
Tom> code Alexander mentioned).
The stb sprintf is indeed a lot faster for floats than other sprintfs,
but (a) it's
On 7 September 2018 at 19:29, David Rowley wrote:
> While reviewing some other patches to improve partitioning performance
> I noticed that one of the loops in ExecFindInitialMatchingSubPlans()
> could be coded a bit more efficiently. The current code loops over
> all the original subplans
On 8 October 2018 at 13:13, Tom Lane wrote:
> The idea I had in mind was to allow hard pruning of any leaf that's
> been excluded *at plan time* based on partition constraints seen in
> its parent rel(s). That should be safe enough as long as we take
> locks on all the non-leaf rels --- then
David Rowley writes:
> On 8 October 2018 at 12:18, Tom Lane wrote:
>> So ISTM that the *real* win for this scenario is going to come from
>> teaching the system to prune unwanted relations from the query
>> altogether, not just from the PlanRowMark list.
> Idle thought: I wonder if we could
On 8 October 2018 at 12:18, Tom Lane wrote:
> However, we should keep in mind that without partitioning overhead
> (ie "select * from lt_999 where b = 999 for share"), the TPS rate
> is over 25800 tps. Most of the overhead in the partitioned case seems
> to be from acquiring locks on rangetable
I wrote:
> Still need to think a bit more about whether we want 0005 in
> anything like its current form.
So I poked at that for a bit, and soon realized that the *main* problem
there is that ExecFindRowMark() eats O(N^2) time due to repeated searches
of the es_rowMarks list. While the patch as
On 5 October 2018 at 04:45, Konstantin Knizhnik
wrote:
> Will the following test be enough:
>
> -- check that columns for parent table are correctly mapped to child
> partition of their order doesn't match
> create table paren (a int, b text) partition by range(a);
> create table child_1
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Now, "shortest value that converts back exactly" is technically
> Tom> cool, but I am not sure that it solves any real-world problem that
> Tom> we have.
> Well, it seems to me that it is perfect for pg_dump.
Perhaps. I was hoping
Disclaimer: I might have done things in not the best way - I'll happily
accept correction.
Here is some information about building on msys2, the rewrite of msys,
plus a proposal for a couple of tiny changes to support it.
The simplest way to install msys2 is via the chocolatey package
Amit Langote writes:
> 0004: removes useless fields from certain planner nodes whose only purpose
> has been to assist the executor lock relations in proper order
I've pushed most of 0004 now; obviously, not the parts removing
PlannedStmt.rowMarks, since that's not possible without rearrangement
Hi,
On 2018-10-07 11:37:20 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Sat, Oct 06, 2018 at 11:43:06PM -0700, Andres Freund wrote:
> >> Now that we probably have shaken the worst issues out of scram,
> >> shouldn't we change the default password_encryption to something that
> >>
new update
minor white space issue
one more regress test and 2 pg_dump tests
Regards
Pavel
>
> Regards
>
> Pavel
>
>
>>
>> Regards
>>
>> Pavel
>>
>>
>>
>>> Regards
>>>
>>> Pavel
>>>
>>
schema-variables-20181007-01.patch.gz
Description: application/gzip
John Naylor writes:
> On 10/6/18, Thomas Munro wrote:
>> On Sat, Oct 6, 2018 at 7:47 AM John Naylor wrote:
>>> A while back, Robert Haas noticed that the space taken up by very
>>> small tables is dominated by the FSM [1]. Tom suggested that we could
>>> prevent creation of the FSM until the
Michael Paquier writes:
> On Sat, Oct 06, 2018 at 11:43:06PM -0700, Andres Freund wrote:
>> Now that we probably have shaken the worst issues out of scram,
>> shouldn't we change the default password_encryption to something that
>> doesn't scare people? The only reason I could think of not
On 10/6/18, Thomas Munro wrote:
> On Sat, Oct 6, 2018 at 7:47 AM John Naylor wrote:
>> A while back, Robert Haas noticed that the space taken up by very
>> small tables is dominated by the FSM [1]. Tom suggested that we could
>> prevent creation of the FSM until the heap has reached a certain
>>
On Sun, Oct 07, 2018 at 11:13:19AM -0300, Alvaro Herrera wrote:
> Good point. I cannot do that today, but if you want to, please go
> ahead.
Okay, done.
--
Michael
signature.asc
Description: PGP signature
On 2018-Oct-07, Michael Paquier wrote:
> On Sat, Oct 06, 2018 at 10:15:32PM -0300, Alvaro Herrera wrote:
> > Pushed to 11 and master. I'm not convinced that it's a good idea to
> > mess with 10 at this point -- the partitioning code is rather completely
> > different already ...
>
> While I
Hello,
I noticed that every parallel worker generates the same sequence of
handles here:
/*
* Loop until we find an unused identifier for the new control
segment. We
* sometimes use 0 as a sentinel value indicating that no
control segment
* is known to exist,
> "Tom" == Tom Lane writes:
Tom> Now, "shortest value that converts back exactly" is technically
Tom> cool, but I am not sure that it solves any real-world problem that
Tom> we have.
Well, it seems to me that it is perfect for pg_dump.
Also it's kind of a problem that our default float
On Sun, Oct 07, 2018 at 05:14:30PM +0900, Michael Paquier wrote:
> Here is a counter-proposal:
> "cannot use ONLY for foreign key on partitioned table \"%s\" referencing
> relation \"%s\""
>
> +-- also, adding a NOT VALID foreign key should fail
> +ALTER TABLE fk_partitioned_fk ADD FOREIGN KEY
On 6 October 2018 at 18:20, Edmund Horner wrote:
> David Rowley said:
>> I am considering this a bug fix, but I'm proposing this for PG12 only
>> as I don't think destabilising plans in the back branches is a good
>> idea. I'll add this to the September commitfest.
>
> I played with the new
On Sat, Oct 06, 2018 at 11:16:09PM +0200, Laurenz Albe wrote:
> True; how about the attached?
>
> I think this should go in before v11.
Thanks for adding regression tests for that.
- errmsg("foreign key referencing partitioned table \"%s\" must not be ONLY",
-
On Sat, Oct 06, 2018 at 11:43:06PM -0700, Andres Freund wrote:
> Now that we probably have shaken the worst issues out of scram,
> shouldn't we change the default password_encryption to something that
> doesn't scare people? The only reason I could think of not wanting to
> do that for is that
On Sat, Oct 06, 2018 at 10:15:32PM -0300, Alvaro Herrera wrote:
> Pushed to 11 and master. I'm not convinced that it's a good idea to
> mess with 10 at this point -- the partitioning code is rather completely
> different already ...
While I definitely agree with you to not mess up with this
Hi,
Now that we probably have shaken the worst issues out of scram,
shouldn't we change the default password_encryption to something that
doesn't scare people? The only reason I could think of not wanting to
do that for is that we don't necessarily guarantee that we have a strong
random
Amit Kapila writes:
> On Sun, Oct 7, 2018 at 10:36 AM Tom Lane wrote:
>> That state is restored at least two transactions too late.
> That is right, but I think we can perform shm_toc_lookup for
> PARALLEL_KEY_TRANSACTION_STATE at some earlier point and then use the
> variables from it to
26 matches
Mail list logo
