On Wed, Nov 8, 2017 at 12:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote:
>>> What I'm getting from the standard pgbench measurements, on both machines,
>>> is that this patch might be a couple percent slower than HEAD, but that is
>>> barely above
On Tue, Nov 7, 2017 at 11:42 AM, Юрий Соколов wrote:
>
>
> 2017-11-07 17:15 GMT+03:00 Claudio Freire :
>> Aside from requiring all that include magic, if you place specialized
>> sort functions in a reusable header, using it is as simple as
>> including the type-specif
On Mon, Nov 6, 2017 at 9:08 PM, Юрий Соколов wrote:
> 2017-11-07 1:14 GMT+03:00 Claudio Freire :
>>
>> I haven't seen this trick used in postgres, nor do I know whether it
>> would be well received, so this is more like throwing an idea to see
>> if it sticks...
&g
On Mon, Nov 6, 2017 at 6:58 PM, Юрий Соколов wrote:
>
> 2017-11-06 17:55 GMT+03:00 Claudio Freire :
>>
>> On Mon, Nov 6, 2017 at 11:50 AM, Юрий Соколов
>> wrote:
>> >> Maybe leave a fallback to qsort if some corner case produces big
>> >> buckets
On Mon, Nov 6, 2017 at 11:50 AM, Юрий Соколов wrote:
>> Maybe leave a fallback to qsort if some corner case produces big buckets?
>
> For 8kb pages, each bucket is per 32 bytes. So, for heap pages it is at
> most 1 heap-tuple per bucket, and for index pages it is at most 2 index
> tuples per bucke
_i < _n; _i += 1) \
>>
>> or maybe just _i++.
>
>
> Shame on me :-(
> I've wrote shell sort several times, so I forgot to recheck myself once
> again.
> And looks like best gap sequence from wikipedia is really best
> ( {301, 132, 57, 23, 10 , 4} in my nota
On Fri, Nov 3, 2017 at 4:30 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>>> BTW, the originally given test case shows no measurable improvement
>>> on my box.
>
>> I did manage to reproduce the original t
On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
> Sokolov Yura writes:
>> [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ]
>
> I started to review this patch. I spent a fair amount of time on
> beautifying the code, because I found it rather ugly and drastically
> undercommented. On
On Sun, Oct 1, 2017 at 8:36 PM, Daniel Gustafsson wrote:
>> On 18 Aug 2017, at 13:39, Claudio Freire wrote:
>>
>> On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire
>> wrote:
>>> Indeed they do, and that's what motivated this patch. But I'd need
>&g
On Sat, Sep 23, 2017 at 5:56 AM, Sokolov Yura
wrote:
> Hello, Claudio.
>
> Thank you for review and confirm of improvement.
>
>
> On 2017-09-23 01:12, Claudio Freire wrote:
>>
>>
>> Patch 1 applies cleanly, builds, and make check runs fine.
>>
>>
On Tue, Sep 12, 2017 at 12:49 PM, Sokolov Yura
wrote:
> On 2017-07-21 13:49, Sokolov Yura wrote:
>>
>> On 2017-05-17 17:46, Sokolov Yura wrote:
>>>
>>> Alvaro Herrera писал 2017-05-15 20:13:
As I understand, these patches are logically separate, so putting them
together in a single
On Fri, Sep 22, 2017 at 4:46 AM, Kyotaro HORIGUCHI
wrote:
> I apologize in advance of possible silliness.
>
> At Thu, 21 Sep 2017 13:54:01 -0300, Claudio Freire
> wrote in
>> On Tue, Sep 19, 2017 at 8:55 PM, Peter Geoghegan wrote:
>> > On Tue, Sep 19, 2017
On Tue, Sep 19, 2017 at 8:55 PM, Peter Geoghegan wrote:
> On Tue, Sep 19, 2017 at 4:47 PM, Claudio Freire
> wrote:
>> Maybe this is looking at the problem from the wrong direction.
>>
>> Why can't the page be added to the FSM immediately and the check be
>>
On Tue, Sep 19, 2017 at 3:31 AM, Kyotaro HORIGUCHI
wrote:
> I was just looking the thread since it is found left alone for a
> long time in the CF app.
>
> At Mon, 18 Sep 2017 16:35:58 -0700, Peter Geoghegan wrote in
>
>> On Wed, Apr 5, 2017 at 3:50 PM, Andres Freund wrote:
>> > Hi,
>> >
>> >
On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire wrote:
> Indeed they do, and that's what motivated this patch. But I'd need
> TB-sized tables to set up something like that. I don't have the
> hardware or time available to do that (vacuum on bloated TB-sized
> tables can
On Fri, Jul 28, 2017 at 8:32 PM, Peter Geoghegan wrote:
> README.HOT says that that cost is not worth the benefit of
> preventing a new index write, but I think that it ought to take into
> account that not all index writes are equal. There is an appreciable
> difference between inserting a new tu
st without major refactoring of the feature.
So, patch attached. I'll add it to the next CF as well.
From 791b9d2006b5abd67a8efb3f7c6cc99141ddbb09 Mon Sep 17 00:00:00 2001
From: Claudio Freire
Date: Fri, 28 Jul 2017 21:31:59 -0300
Subject: [PATCH] Vacuum: Update FSM more frequently
Make Vacuum
On Thu, Jul 27, 2017 at 2:10 PM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>> On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
>> wrote:
>> > Claudio Freire wrote:
>> >
>> >> > The vacuuming the very large table with no index could also ta
On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>
>> > The vacuuming the very large table with no index could also take a
>> > long time, and it scans and vacuums blocks one by one. So I imagined
>> > that we can vacuum the FSM
On Thu, Jul 27, 2017 at 6:16 AM, Masahiko Sawada wrote:
> On Thu, Jul 27, 2017 at 5:48 PM, Sokolov Yura
> wrote:
>> On 2017-07-27 11:30, Masahiko Sawada wrote:
>>>
>>> On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire
>>> wrote:
>>>>
&
On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura
wrote:
> On 2017-07-24 12:41, Sokolov Yura wrote:
> test_master_1/pretty.log
...
> time activity tps latency stddev min max
> 11130 av+ch 198198ms374ms 7ms 1956ms
> 11160 av+ch 248163ms401ms
On Mon, Jul 24, 2017 at 2:43 PM, Peter Geoghegan wrote:
> On Mon, Jul 24, 2017 at 10:13 AM, Claudio Freire
> wrote:
>> Vacuum *might* be able to redistribute tuples too, while holding locks
>> to all 3 pages (the two children and the parent page), since it can
>> mo
On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire wrote:
> On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
> wrote:
>> On 2017-07-24 19:11, Claudio Freire wrote:
>>> I was mostly thinking about something like the attached patch.
>>>
>>> Simple, unintrus
On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
wrote:
> On 2017-07-24 19:11, Claudio Freire wrote:
>>
>> On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
>> wrote:
>>>
>>> Good day, Claudio
>>>
>>>
>>> On 2017-07-22 00:27, Claudio Fre
On Mon, Jul 24, 2017 at 2:02 PM, Peter Geoghegan wrote:
> On Mon, Jul 24, 2017 at 9:51 AM, Claudio Freire
> wrote:
>> My point was that the TID doesn't have to point to an actual tuple.
>>
>> It's more of a keyspace thing, so it doesn't need to match
On Wed, Nov 23, 2016 at 12:27 AM, Peter Geoghegan wrote:
> On Mon, Nov 21, 2016 at 5:15 PM, Claudio Freire
> wrote:
>>> There are a couple
>>> of tricky issues with that that you'd have to look out for, like
>>> making sure that the high key continues to
On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
wrote:
> Good day, Claudio
>
>
> On 2017-07-22 00:27, Claudio Freire wrote:
>>
>> On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
>> wrote:
>>>
>>>
>>> My friend noticed, that I didn't sai
On Fri, Jul 21, 2017 at 10:31 PM, Peter Geoghegan wrote:
> On Wed, Aug 17, 2016 at 7:54 PM, Claudio Freire
> wrote:
>> The attached patch tries to maintain the initial status of B-Tree
>> indexes, which are created with equal-key runs in physical order,
>> during the
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
wrote:
>
> My friend noticed, that I didn't said why I bother with autovacuum.
> Our customers suffers from table bloating. I've made synthetic
> bloating test, and started experiments with modifying micro- and
> auto-vacuum. My first attempts were to
On Thu, Jul 20, 2017 at 1:08 PM, Claudio Freire wrote:
> So, the 64x increase may be justifiable in absolute terms: it's not
> unlikely that a 16MB buffer will be evicted from the OS cache before
> vacuum is done with it, even in heavily throttled vacuums.
Sorry, that should
On Thu, Jul 20, 2017 at 12:51 PM, Robert Haas wrote:
> On Thu, Jul 20, 2017 at 11:09 AM, Claudio Freire
> wrote:
>>> It's no secret that making the ring buffer larger will improve
>>> performance -- in fact, not having a ring buffer at all would improve
>>>
On Thu, Jul 20, 2017 at 11:59 AM, Robert Haas wrote:
> On Tue, Jul 18, 2017 at 6:09 AM, Sokolov Yura
> wrote:
>> I investigated autovacuum performance, and found that it suffers a lot
>> from small ring buffer. It suffers in a same way bulk writer suffered
>> before Tom Lane's commit 6382448cf96:
On Thu, Jul 20, 2017 at 12:08 AM, Peter Geoghegan wrote:
>> The traditional
>> wisdom about btrees, for instance, is that no matter how full you pack
>> them to start with, the steady state is going to involve something like
>> 1/3rd free space. You can call that bloat if you want, but it's not
>
On Wed, Jul 12, 2017 at 1:29 PM, Claudio Freire wrote:
> On Wed, Jul 12, 2017 at 1:08 PM, Claudio Freire
> wrote:
>> On Wed, Jul 12, 2017 at 11:48 AM, Alexey Chernyshov
>> wrote:
>>> Thank you for the patch and benchmark results, I have a couple remar
On Wed, Jul 12, 2017 at 1:08 PM, Claudio Freire wrote:
> On Wed, Jul 12, 2017 at 11:48 AM, Alexey Chernyshov
> wrote:
>> Thank you for the patch and benchmark results, I have a couple remarks.
>> Firstly, padding in DeadTuplesSegment
>>
>> ty
se the compiler will do this optimization
> itself.
I'll look into it. But my experience is that compilers won't align
struct size like this, only attributes, and this attribute is composed
of 16-bit attributes so it doesn't get aligned by default.
> On 11.07.2017
, which may
be related to the search implementation being better somehow, and a
slowdown at scale 4000 in some variants. I believe this is due to
those variants having highly clustered indexes. While the "shuf"
(shuffled) variantes were intended to be the opposite of that, I
suspect I so
On Mon, Jul 10, 2017 at 3:40 PM, Peter Geoghegan wrote:
> It might appear excessive to talk about several different techniques
> in one place, but that seemed like the best way to me, because there
> are subtle dependencies. If most of the optimizations are pursued as a
> project all at once (say,
On Fri, Jun 2, 2017 at 11:46 AM, Teodor Sigaev wrote:
>> There were old threads about considering a risk factor when estimating
>> plans, and I'm thinking this issue is the planner failing to do
>> exactly that.
>>
> I'm afraid it's tool late for v10
Clearly
--
Sent via pgsql-hackers mailing l
On Fri, Jun 2, 2017 at 10:27 AM, Tom Lane wrote:
> Teodor Sigaev writes:
>>> Teodor, could you check if this patch fixes your real-world problem?
>
>> It works fine with original query, thank you. But some other query slowdowns
>> for
>> ~10% (9 secs vs 10 secs). Look at following part of plans
On Mon, May 29, 2017 at 3:53 PM, Bruce Momjian wrote:
> Right now we don't document that temp_tablespaces can use
> non-restart-safe storage, e.g. /tmp, ramdisks. Would this be safe?
> Should we document this?
I have set up things like that, but it's nontrivial.
Just pointing the tablespace to
On Wed, May 3, 2017 at 11:31 AM, David Fetter wrote:
> On Wed, May 03, 2017 at 11:26:27AM -0300, Claudio Freire wrote:
>> On Wed, May 3, 2017 at 2:19 AM, Craig Ringer wrote:
>> >> Or we will choose WITH MATERIALIZE, and then the users aware of
>> >> the fen
On Wed, May 3, 2017 at 2:19 AM, Craig Ringer wrote:
>> Or we will choose WITH MATERIALIZE, and then the users aware of the fencing
>> (and using the CTEs for that purpose) will have to modify the queries. But
>> does adding MATERIALIZE quality as major query rewrite?
>
> Hardly.
>
>> Perhaps combi
On Tue, Apr 25, 2017 at 2:45 PM, Bruce Momjian wrote:
> On Tue, Apr 25, 2017 at 10:37:48AM -0700, Andres Freund wrote:
>> On 2017-04-25 13:11:32 -0400, Bruce Momjian wrote:
>> > I don't think this warrants inclusion in the release notes for reasons
>> > already discussed. The vacuum truncation op
On Tue, Apr 25, 2017 at 2:11 PM, Bruce Momjian wrote:
> On Tue, Apr 25, 2017 at 01:37:13PM -0300, Claudio Freire wrote:
>> > I think it has been pretty common to accumulate a lot of such changes
>> > into generic entries like, say, "speedups for hash joins". Mo
this patch (that was on a slow disk, but it shouldn't hurt on fast
disks.)
Author: Álvaro Herrera, loosely based on a submission by Claudio Freire
Discussion:
https://postgr.es/m/cagtbqpa6nfgo_6g_y_7zqx8l9gchdsqkydo1tguh791z6py...@mail.gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Apr 23, 2017 at 12:41 PM, Robert Haas wrote:
>> That's after inlining the compare on both the linear and sequential
>> code, and it seems it lets the compiler optimize the binary search to
>> the point where it outperforms the sequential search.
>>
>> That's not the case when the compare i
On Wed, Apr 12, 2017 at 4:35 PM, Robert Haas wrote:
> On Tue, Apr 11, 2017 at 4:38 PM, Claudio Freire
> wrote:
>> In essence, the patch as it is proposed, doesn't *need* a binary
>> search, because the segment list can only grow up to 15 segments at
>> its big
On Tue, Apr 11, 2017 at 4:17 PM, Robert Haas wrote:
> On Tue, Apr 11, 2017 at 2:59 PM, Claudio Freire
> wrote:
>> On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote:
>>> 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of
>>> maintenance_work
On Tue, Apr 11, 2017 at 3:59 PM, Claudio Freire wrote:
> On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote:
>> 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of
>> maintenance_work_mem
>>
>> So we'll allocate 128MB+256MB+512MB+1GB+2GB+4GB w
On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote:
> 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of
> maintenance_work_mem
>
> So we'll allocate 128MB+256MB+512MB+1GB+2GB+4GB which won't be quite
> enough so we'll allocate another 8GB, for a total of 16256MB, but more
> tha
On Fri, Apr 7, 2017 at 10:06 PM, Claudio Freire wrote:
>>> >> + if (seg->num_dead_tuples >= seg->max_dead_tuples)
>>> >> + {
>>> >> + /*
>>> >> + *
On Fri, Apr 7, 2017 at 10:12 PM, Andres Freund wrote:
> On 2017-04-07 22:06:13 -0300, Claudio Freire wrote:
>> On Fri, Apr 7, 2017 at 9:56 PM, Andres Freund wrote:
>> > Hi,
>> >
>> >
>> > On 2017-04-07 19:43:39 -0300, Claudio Freire wrote:
>&g
On Fri, Apr 7, 2017 at 9:56 PM, Andres Freund wrote:
> Hi,
>
>
> On 2017-04-07 19:43:39 -0300, Claudio Freire wrote:
>> On Fri, Apr 7, 2017 at 5:05 PM, Andres Freund wrote:
>> > Hi,
>> >
>> > I've *not* read the history of this threa
On Fri, Apr 7, 2017 at 5:05 PM, Andres Freund wrote:
> Hi,
>
> I've *not* read the history of this thread. So I really might be
> missing some context.
>
>
>> From e37d29c26210a0f23cd2e9fe18a264312fecd383 Mon Sep 17 00:00:00 2001
>> From: Claudio Freire
>&
On Fri, Apr 7, 2017 at 7:43 PM, Claudio Freire wrote:
>>> + * Lookup in that structure proceeds sequentially in the list of segments,
>>> + * and with a binary search within each segment. Since segment's size grows
>>> + * exponentially, this retains O(N log N) loo
On Fri, Apr 7, 2017 at 2:28 AM, David Rowley
wrote:
>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
>> DEFAULT_INEQ_SEL)
>> + {
>> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL
>> implies we have no stats */
>> + s2 = DEFAULT_RANGE_INEQ_SEL;
>> + }
>> + el
On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote:
>>> If you ask me, I'd just leave:
>>>
>>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound ==
>>> DEFAULT_INEQ_SEL)
>>> + {
>>> + /* No point in checkin
On Tue, Apr 4, 2017 at 8:21 AM, David Rowley
wrote:
> On 4 April 2017 at 13:35, Claudio Freire wrote:
>> On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire
>> wrote:
>>> On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
>>>
On Tue, Apr 4, 2017 at 8:12 AM, David Rowley
wrote:
> Result Comparison
>
> Master median tps Patch median tps comparison
> Test 1 6993.7 6714.3 104.16%
> Test 2 7053.1 6921.6 101.90%
> Test 3 5137.2 4954.2 103.69%
> Test 4 27.1 19.4 139.72%
> Test 5 54.1 51.4 105.28%
> Test 6 9328.1 9478.2 98.42%
On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote:
> On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
> wrote:
>>> One last observation:
>>>
>>> +/*
>>> + * An IS NOT NULL test is a no-op if there's any other strict
>>>
On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
wrote:
>> One last observation:
>>
>> +/*
>> + * An IS NOT NULL test is a no-op if there's any other strict quals,
>> + * so if that's the case, then we'll only apply this, otherwise
>> we'll
>> + * ignore it.
>> +
On Mon, Apr 3, 2017 at 5:59 AM, David Rowley
wrote:
>> +static void addCachedSelectivityRangeVar(CachedSelectivityClause
>> **cslist, Node *var,
>> bool varonleft, bool isLTsel, Selectivity s2);
>>
>> You're changing clause -> var throughout the code when dealing with
>> nodes, but
On Mon, Apr 3, 2017 at 6:22 PM, David Rowley
wrote:
> On 4 April 2017 at 08:24, Andres Freund wrote:
>> On 2017-04-03 20:59:42 +1200, David Rowley wrote:
>>> Updated patch attached.
>>>
>>> Thanks for reviewing it.
>>
>> Given the time in the release cycle I'm afraid that this it's too late
>> to
On Mon, Apr 3, 2017 at 5:24 PM, Andres Freund wrote:
> On 2017-04-03 20:59:42 +1200, David Rowley wrote:
>> Updated patch attached.
>>
>> Thanks for reviewing it.
>
> Given the time in the release cycle I'm afraid that this it's too late
> to get this into v10. Does anybody disagree? If not, it
On Fri, Feb 24, 2017 at 7:00 AM, David Rowley
wrote:
> I've stumbled over an interesting query out in the wild where the
> query was testing a nullable timestamptz column was earlier than some
> point in time, and also checking the column IS NOT NULL.
>
> The use pattern here was that records whic
On Wed, Feb 1, 2017 at 7:55 PM, Claudio Freire wrote:
> On Wed, Feb 1, 2017 at 6:13 PM, Masahiko Sawada wrote:
>> On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire
>> wrote:
>>> On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada
>>> wrote:
>>>> Than
On Fri, Feb 24, 2017 at 1:24 PM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 7:29 PM, Kohei KaiGai wrote:
>> This attached patch re-designed the previous v2 according to Robert's
>> comment.
>> All I had to do is putting entrypoint for ForeignScan/CustomScan at
>> ExecShutdownNode,
>> because i
On Wed, Feb 15, 2017 at 9:52 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 11:45 PM, Tom Lane wrote:
>> You could perhaps make an argument that sum(float4) would have less risk
>> of overflow if it accumulated in and returned float8, but frankly that
>> seems a bit thin.
>
> I think that's mor
On Thu, Feb 9, 2017 at 9:50 PM, Jim Nasby wrote:
> WHERE t1 IN ('a','b') OR t2 IN ('c','d')
>
> into
>
> WHERE f1 IN (1,2) OR f2 IN (3,4)
>
> (assuming a,b,c,d maps to 1,2,3,4)
>
> BTW, there's an important caveat here: users generally do NOT want duplicate
> rows from the fact table if the dimens
On Mon, Feb 6, 2017 at 1:42 AM, Kouhei Kaigai wrote:
> I also had thought an idea to have extra space to Instrumentation structure,
> however, it needs to make Instrumentation flexible-length structure according
> to the custom format by CSP/FDW. Likely, it is not a good design.
> As long as exten
On Mon, Feb 6, 2017 at 1:00 AM, Claudio Freire wrote:
> On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote:
>>> If the use case for this is to gather instrumentation, I'd suggest calling
>>> the hook in RetrieveInstrumentation, and calling it appropriately. It would
On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote:
>> If the use case for this is to gather instrumentation, I'd suggest calling
>> the hook in RetrieveInstrumentation, and calling it appropriately. It would
>> make the intended use far clearer than it is now.
>>
>> And if it saves some work, al
On Mon, Oct 31, 2016 at 11:33 AM, Kouhei Kaigai wrote:
> Hello,
>
> The attached patch implements the suggestion by Amit before.
>
> What I'm motivated is to collect extra run-time statistics specific
> to a particular ForeignScan/CustomScan, not only the standard
> Instrumentation; like DMA trans
On Wed, Feb 1, 2017 at 6:13 PM, Masahiko Sawada wrote:
> On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire
> wrote:
>> On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada
>> wrote:
>>> Thank you for updating the patch.
>>>
>>> Whole patch looks go
On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada wrote:
> Thank you for updating the patch.
>
> Whole patch looks good to me except for the following one comment.
> This is the final comment from me.
>
> /*
> * lazy_tid_reaped() -- is a particular tid deletable?
> *
> * This has the right
ug in
lazy_clear_dead_tuples, so clearly it's not without merit.
I'll rearrange the comments as you ask though.
Updated and rebased v7 attached.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776671
From d32610b0ad6b9413aa4b2d808019d3c67d578f3c Mon Sep 17 00:00:00 2001
From:
always set later I think the first line starting with
> "seg = ..." is not necessary. Thought?
That's correct.
Attached a v6 with those changes (and rebased).
Make check still passes.
From c89019089a71517befac0920f22ed75577dda6c6 Mon Sep 17 00:00:00 2001
From: Claudio Freire
On Fri, Jan 20, 2017 at 6:24 AM, Masahiko Sawada wrote:
> On Thu, Jan 19, 2017 at 8:31 PM, Claudio Freire
> wrote:
>> On Thu, Jan 19, 2017 at 6:33 AM, Anastasia Lubennikova
>> wrote:
>>> 28.12.2016 23:43, Claudio Freire:
>>>
>>> Attached v4 patche
On Thu, Jan 19, 2017 at 6:33 AM, Anastasia Lubennikova
wrote:
> 28.12.2016 23:43, Claudio Freire:
>
> Attached v4 patches with the requested fixes.
>
>
> Sorry for being late, but the tests took a lot of time.
I know. Takes me several days to run my test scripts once.
&g
On Tue, Jan 10, 2017 at 6:42 AM, Masahiko Sawada wrote:
>> Does this work negate the other work to allow VACUUM to use >
>> 1GB memory?
>
> Partly yes. Because memory space for dead TIDs needs to be allocated
> in DSM before vacuum worker launches, parallel lazy vacuum cannot use
> such a variable
On Tue, Jan 10, 2017 at 6:42 AM, Masahiko Sawada wrote:
> Attached result of performance test with scale factor = 500 and the
> test script I used. I measured each test at four times and plot
> average of last three execution times to sf_500.png file. When table
> has index, vacuum execution time
On Fri, Jan 6, 2017 at 2:38 PM, Masahiko Sawada wrote:
> table_size | indexes | parallel_degree | time
> +-+-+--
> 6.5GB | 0 | 1 | 00:00:14
> 6.5GB | 0 | 2 | 00:00:02
> 6.5GB | 0 |
On Wed, Dec 28, 2016 at 3:41 PM, Claudio Freire wrote:
>> Anyway, I found the problem that had caused segfault.
>>
>> for (segindex = 0; segindex <= vacrelstats->dead_tuples.last_seg; tupindex =
>> 0, segindex++)
>> {
>> DeadTuplesSegment *seg =
On Wed, Dec 28, 2016 at 10:26 AM, Anastasia Lubennikova
wrote:
> 27.12.2016 20:14, Claudio Freire:
>
> On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova
> wrote:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x006941e7 in lazy_vacuum_h
On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova
wrote:
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x006941e7 in lazy_vacuum_heap (onerel=0x1ec2360,
> vacrelstats=0x1ef6e00) at vacuumlazy.c:1417
> 1417tblk =
> ItemPointerGetBlockNumber(&seg->
ather than global index).
On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova
wrote:
> 23.12.2016 22:54, Claudio Freire:
>
> On Fri, Dec 23, 2016 at 1:39 PM, Anastasia Lubennikova
> wrote:
>
> I found the reason. I configure postgres with CFLAGS="-O0" and it causes
On Fri, Dec 23, 2016 at 1:39 PM, Anastasia Lubennikova
wrote:
>> On Thu, Dec 22, 2016 at 12:22 PM, Claudio Freire
>> wrote:
>>>
>>> On Thu, Dec 22, 2016 at 12:15 PM, Anastasia Lubennikova
>>> wrote:
>>>>
>>>> The following revie
On Thu, Dec 22, 2016 at 12:22 PM, Claudio Freire wrote:
> On Thu, Dec 22, 2016 at 12:15 PM, Anastasia Lubennikova
> wrote:
>> The following review has been posted through the commitfest application:
>> make installcheck-world: tested, failed
>> Implements feature:
On Thu, Dec 22, 2016 at 12:15 PM, Anastasia Lubennikova
wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
On Mon, Nov 21, 2016 at 5:42 PM, Peter Geoghegan wrote:
>>> Or, you might want to make
>>> sure that B-Tree tuple insertions still find that "first page" to
>>> check, despite still generally treating heap item pointer as part of
>>> the key proper (in unique indexes, it can still behave like NULL
On Mon, Nov 21, 2016 at 2:15 PM, Masahiko Sawada wrote:
> On Fri, Nov 18, 2016 at 6:54 AM, Claudio Freire
> wrote:
>> On Thu, Nov 17, 2016 at 6:34 PM, Robert Haas wrote:
>>> On Thu, Nov 17, 2016 at 1:42 PM, Claudio Freire
>>> wrote:
>>>> Attached i
On Fri, Nov 18, 2016 at 11:09 PM, Peter Geoghegan wrote:
> On Fri, Nov 18, 2016 at 5:27 PM, Claudio Freire
> wrote:
>> I've been changing the on-disk format considerably, to one that makes
>> more sense.
>
> I can see how that would be necessary. I'm going
On Fri, Nov 18, 2016 at 10:05 PM, Peter Geoghegan wrote:
> On Thu, Aug 18, 2016 at 2:15 PM, Peter Geoghegan wrote:
>> I think that this is a bad idea. We need to implement suffix
>> truncation of internal page index tuples at some point, to make them
>> contain less information from the original
On Thu, Nov 17, 2016 at 6:34 PM, Robert Haas wrote:
> On Thu, Nov 17, 2016 at 1:42 PM, Claudio Freire
> wrote:
>> Attached is patch 0002 with pgindent applied over it
>>
>> I don't think there's any other formatting issue, but feel free to
>> point a fin
On Thu, Nov 17, 2016 at 2:51 PM, Claudio Freire wrote:
> On Thu, Nov 17, 2016 at 2:34 PM, Masahiko Sawada
> wrote:
>> I glanced at the patches but the both patches don't obey the coding
>> style of PostgreSQL.
>> Please refer to [1].
>>
>> [1]
>>
On Thu, Nov 17, 2016 at 2:34 PM, Masahiko Sawada wrote:
> I glanced at the patches but the both patches don't obey the coding
> style of PostgreSQL.
> Please refer to [1].
>
> [1]
> http://wiki.postgresql.org/wiki/Developer_FAQ#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F.
I t
On Wed, Oct 26, 2016 at 9:33 PM, Peter Geoghegan wrote:
> Besides, parallel CREATE INDEX alone will probably
> be quite effective at speeding up CLUSTER in practice, simply because
> that's often where most wall clock time is spent during a CLUSTER
> operation.
Creating all indexes in parallel co
On Thu, Oct 20, 2016 at 1:08 PM, Pavan Deolasee
wrote:
> On Thu, Oct 20, 2016 at 9:20 PM, Claudio Freire
> wrote:
>>
>>
>>
>> With indirect indexes, since you don't need to insert a tid, you can
>> just "insert on conflict do nothing" on the i
On Thu, Oct 20, 2016 at 12:30 PM, Pavan Deolasee
wrote:
>
>
> On Thu, Oct 20, 2016 at 8:44 PM, Petr Jelinek wrote:
>>
>>
>>
>> WARM can do WARM update 50% of time, indirect index can do HOT update
>> 100% of time (provided the column is not changed), I don't see why we
>> could not have both solu
1 - 100 of 476 matches
Mail list logo
