On Tue, Sep 6, 2016 at 3:45 AM, Simon Riggs wrote:
> On 5 September 2016 at 21:58, Claudio Freire wrote:
>
> How long does that part ever take? Is there any substantial gain from
> this?
>
>> Btw, without a further patch to prefetch pages on the backward scan
>> for truncate, however, my
Robert Haas writes:
> On Mon, Sep 5, 2016 at 11:40 PM, Tom Lane wrote:
>> ... And again, it's
>> hard to get excited about having these options for RENAME VALUE when no
>> one has felt a need for them yet in RENAME COLUMN. I'm especially dubious
>> about IF NOT EXISTS against the destination nam
On Sun, Sep 4, 2016 at 7:05 PM, Jim Nasby wrote:
> On 9/3/16 2:35 PM, Tom Lane wrote:
>
>> I pushed the patch using this:
>>
>> Time: 176460001.200 ms (2 d 01:01:00.001)
>>
>> and all else as before.
>>
>
> I'd find this useful in the final output of EXPLAIN ANALYZE as well; any
> objections to a
Corey Huinker writes:
> On Sun, Sep 4, 2016 at 7:05 PM, Jim Nasby wrote:
>> I'd find this useful in the final output of EXPLAIN ANALYZE as well; any
>> objections to adding it?
> It's sorta out of my hands now, but what Tom said earlier is that because
> this is client-side code, it wouldn't use
Hi
2016-09-06 0:05 GMT+02:00 Tom Lane :
> I wrote:
> > Pavel Stehule writes:
> >> Using footer for this purpose is little bit strange. What about
> following
> >> design?
> >> 1. move out source code of PL functions from \df+
> >> 2. allow not unique filter in \sf and allow to display multiple
>
On 6 September 2016 at 19:23, Robert Haas wrote:
> On Tue, Sep 6, 2016 at 2:16 PM, Simon Riggs wrote:
>> What occurs to me is that we can exactly predict how many tuples we
>> are going to get when we autovacuum, since we measure that and we know
>> what the number is when we trigger it.
>>
>> So
On Tue, Sep 6, 2016 at 2:51 PM, Simon Riggs wrote:
> On 6 September 2016 at 19:23, Robert Haas wrote:
>> On Tue, Sep 6, 2016 at 2:16 PM, Simon Riggs wrote:
>>> What occurs to me is that we can exactly predict how many tuples we
>>> are going to get when we autovacuum, since we measure that and w
On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut
wrote:
>> Joy, do you have an idea what a *minimally invasive* patch for C++
>> support would look like? That's certainly the first step here.
>
> I developed a minimally invasive patch for C++ support a few years ago
> shortly after I wrote that b
On 08/31/2016 04:41 PM, Peter Eisentraut wrote:
I developed a minimally invasive patch for C++ support a few years ago
shortly after I wrote that blog post. Since there appears to have been
some interest here now, I have updated that and split it up into logical
chunks.
So here you go.
Lookin
Simon Riggs writes:
> On 6 September 2016 at 19:23, Robert Haas wrote:
>> On Tue, Sep 6, 2016 at 2:16 PM, Simon Riggs wrote:
>>> What occurs to me is that we can exactly predict how many tuples we
>>> are going to get when we autovacuum, since we measure that and we know
>>> what the number is w
On 08/29/2016 06:52 AM, Fujii Masao wrote:
> Also I like the following Simon's idea.
>
> https://www.postgresql.org/message-id/canp8+jlhfbvv_pw6grasnupw+bdk5dctu7gwpnap-+-zwvk...@mail.gmail.com
> ---
> * first k (n1, n2, n3) – does the same as k (n1, n2, n3) does now
> * any k
On 06/09/16 20:14, Peter Eisentraut wrote:
On 9/3/16 5:14 AM, Petr Jelinek wrote:
What are the BKI_ROWTYPE_OID assignments for? Are they necessary
here? (Maybe this was just copied from pg_subscription?)
Yes they are.
Please explain/document why. It does not match other catalogs, which
e
On Tue, Sep 6, 2016 at 5:20 AM, Heikki Linnakangas wrote:
> I wrote a quick patch to test that, attached. It seems to improve
> performance, at least in this small test case:
>
> create table lotsofints(i integer);
> insert into lotsofints select random() * 10.0 from
> generate_series(1, 1
Christian Convey writes:
> Could someone help me with a few procedural questions?
> (1) This page: https://wiki.postgresql.org/wiki/Reviewing_a_Patch
> lists the current commitfest's manager as "(vacant)". But this page:
> https://commitfest.postgresql.org/ seems to indicate that a commitfest
>
On Tue, Sep 6, 2016 at 3:12 PM, Tom Lane wrote:
>> (2) It seems like there are still a few big questions about this commit:
>>- Is it wanted at the moment? It didn't seem like there's a
>> consensus about whether or not this enhancement should be
>> merged, even if the patch is pret
On Tue, Sep 6, 2016 at 12:08 PM, Peter Geoghegan wrote:
> Offhand, I would think that taken together this is very important. I'd
> certainly want to see cases in the hundreds of megabytes or gigabytes
> of work_mem alongside your 4MB case, even just to be able to talk
> informally about this. As y
On 09/06/2016 04:49 AM, Amit Kapila wrote:
> On Mon, Sep 5, 2016 at 11:34 PM, Tomas Vondra
> wrote:
>>
>>
>> On 09/05/2016 06:03 AM, Amit Kapila wrote:
>>> So, in short we have to compare three
>>> approaches here.
>>>
>>> 1) Group mode to reduce CLOGControlLock contention
>>> 2) Use granular l
On Tue, Sep 6, 2016 at 12:08 AM, Heikki Linnakangas wrote:
>> I attach a patch that changes how we maintain the heap invariant
>> during tuplesort merging.
> Nice!
Thanks!
>> This new approach is more or less the *conventional* way to maintain
>> the heap invariant when returning elements from
On Tue, Sep 6, 2016 at 12:39 PM, Peter Geoghegan wrote:
> On Tue, Sep 6, 2016 at 12:08 AM, Heikki Linnakangas wrote:
>>> I attach a patch that changes how we maintain the heap invariant
>>> during tuplesort merging.
>
>> Nice!
>
> Thanks!
BTW, the way that k-way merging is made more efficient by
I wrote:
> I see. The comment could do with a bit of rewriting, perhaps.
I rewrote the comment and pushed it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On Tue, Sep 6, 2016 at 12:51 PM, Tom Lane wrote:
> I rewrote the comment and pushed it.
Thank you.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 15, 2016 at 9:33 PM, Peter Geoghegan wrote:
> The patch is intended to be applied on top of parallel B-Tree patches
> 0001-* and 0002-* [1]. I happened to test it with parallelism, but
> these are all independently useful, and will be entered as a separate
> CF entry (perhaps better to
On 09/06/2016 02:30 PM, Tom Lane wrote:
Robert Haas writes:
On Mon, Sep 5, 2016 at 11:40 PM, Tom Lane wrote:
... And again, it's
hard to get excited about having these options for RENAME VALUE when no
one has felt a need for them yet in RENAME COLUMN. I'm especially dubious
about IF NOT EX
Craig Ringer writes:
> Tom, any preference here?
> I'm probably inclined to go for your original wording and accept that
> it's just too hard to hint at the client/server process split in a
> single short message.
I think my original wording is pretty hopeless for the single-machine
case: "COPY c
Hi
2016-09-06 6:54 GMT+02:00 Craig Ringer :
> On 4 September 2016 at 16:06, Pavel Stehule
> wrote:
> > Hi
> >
> > minor update - using DefElem instead own private parser type
>
> I'm really glad that you're doing this and I'll take a look at it for this
> CF.
>
> It's quite a big patch so I expe
Andrew Dunstan writes:
> Are we also going to have an exists test for the original thing being
> renamed? Exists tests on renames do strike me as somewhat cumbersome, to
> say the least.
I'm less opposed to that part, because it's at least got *some* precedent
in existing RENAME features. But
Re: Tom Lane 2016-09-06 <17637.1473192...@sss.pgh.pa.us>
> Christoph's idea isn't bad. We could tweak it to:
>
> COPY TO instructs the PostgreSQL server process to write a file.
>
> COPY FROM instructs the PostgreSQL server process to read a file.
>
> This seems to cover both the wr
> libxml2 and our XPATH function doesn't support default namespace (
> http://plasmasturm.org/log/259/ ). This is pretty useful feature - so I
> implemented. This is the mayor issue of libxml2 library. Another difference
> between XPATH function and XMLTABLE function is using two phase searching
>
On Tue, Sep 6, 2016 at 12:34 AM, Heikki Linnakangas wrote:
> I'm reviewing patches 1-3 in this series, i.e. those patches that are not
> directly related to parallelism, but are independent improvements to
> merging.
That's fantastic! Thanks!
I'm really glad you're picking those ones up. I feel
On 2016-06-03 01:45, Thomas Munro wrote:
On Fri, Jun 3, 2016 at 4:02 AM, Alvaro Herrera wrote:
Tom Lane wrote:
Andres Freund writes:
pg_strtoi?
I think that's what Thomas did upthread. Are you taking this one then?
I'd go with just "strtoint". We have "strtoint64" elsewhere.
For clos
On Tue, Sep 6, 2016 at 2:46 PM, Peter Geoghegan wrote:
> Feel free to make a counter-proposal for a cap. I'm not attached to
> 500. I'm mostly worried about blatant waste with very large workMem
> sizings. Tens of thousands of tapes is just crazy. The amount of data
> that you need to have as inpu
On 7 Sep. 2016 02:14, "Corey Huinker" wrote:
>
> Having regression tests for this is extremely problematic, because the
program invoked would need to be an invokable command on any architecture
supported by postgres. I'm pretty sure no such command exists.
Your best bet will be using the TAP fra
Peter Eisentraut writes:
> Here are two WIP patches to improve the DefElem list processing that is
> used by many utility commands.
> One factors out the duplicate checks, which are currently taking up a
> lot of space with duplicate code. I haven't applied this everywhere
> yet, but the patch s
On Tue, Sep 6, 2016 at 12:57 PM, Claudio Freire wrote:
> Patch lacks any new tests, but the changed code paths seem covered
> sufficiently by existing tests. A little bit of fuzzing on the patch
> itself, like reverting some key changes, or flipping some key
> comparisons, induces test failures as
On Wed, Sep 7, 2016 at 7:53 AM, Craig Ringer
wrote:
> On 7 Sep. 2016 02:14, "Corey Huinker" wrote:
>>
>
>> Having regression tests for this is extremely problematic, because the
>> program invoked would need to be an invokable command on any architecture
>> supported by postgres. I'm pretty sure
On Tue, Sep 6, 2016 at 8:28 PM, Peter Geoghegan wrote:
> On Tue, Sep 6, 2016 at 12:57 PM, Claudio Freire
> wrote:
>> Patch lacks any new tests, but the changed code paths seem covered
>> sufficiently by existing tests. A little bit of fuzzing on the patch
>> itself, like reverting some key chang
>> On 06 Sep 2016, at 12:03, Michael Paquier wrote:
>>
>> On Tue, Sep 6, 2016 at 5:58 PM, Stas Kelvich
>> wrote:
>>> Oh, I was preparing new version of patch, after fresh look on it. Probably,
>>> I should
>>> said that in this topic. I’ve found a bug in sub transaction handling and
>>> now wo
On Tue, Sep 6, 2016 at 4:55 PM, Claudio Freire wrote:
> I noticed, but here n = state->memtupcount
>
> + Assert(memtuples[0].tupindex == newtup->tupindex);
> +
> + CHECK_FOR_INTERRUPTS();
> +
> + n = state->memtupcount; /* n is heap's size,
> including old root */
On Tue, Sep 6, 2016 at 9:19 PM, Peter Geoghegan wrote:
> On Tue, Sep 6, 2016 at 4:55 PM, Claudio Freire wrote:
>> I noticed, but here n = state->memtupcount
>>
>> + Assert(memtuples[0].tupindex == newtup->tupindex);
>> +
>> + CHECK_FOR_INTERRUPTS();
>> +
>> + n = state->memtupco
On Tue, Sep 6, 2016 at 5:50 PM, Claudio Freire wrote:
> However, I agree that it's not worth the risk conflating the two
> optimizations. That one can be done later as a separate patch.
I'm rather fond of the assertions about tape number that exist within
root_displace currently. But, yeah, maybe
Review of 0002-Add-SUBSCRIPTION-catalog-and-DDL.patch:
(As you had already mentioned, some of the review items in 0001 apply
analogously here.)
Changes needed to compile:
--- a/src/backend/commands/subscriptioncmds.c
+++ b/src/backend/commands/subscriptioncmds.c
@@ -218,7 +218,7 @@ CreateSubscr
On Tue, Sep 6, 2016 at 10:40 AM, Doug Doole wrote:
>> The ICU ABI (not API) is also versioned. The way that this is done is
>> that all functions are actually macros to a versioned symbol. So
>> ucol_open() is actually a macro that expands to, say, ucol_open_57() in
>> ICU version 57. (They als
On Fri, Aug 19, 2016 at 12:38 PM, Jim Nasby
wrote:
> On 8/18/16 5:01 PM, Tom Lane wrote:
>
>> I agree, but I think mandating a database name (which I suppose could be
>>> > *) with the specifiers would solve that issue.
>>>
>> Hmm, something like "-T dbname1:pattern1 -T dbname2:pattern2" ?
>>
>
>
On Tue, Sep 6, 2016 at 10:40 AM, Doug Doole wrote:
> - Suppose in ICU X.X, AA = Å but in ICU Y.Y AA != Å. Further suppose there
> was an RI constraint where the primary key used AA and the foreign key used
> Å. If ICU was updated, the RI constraint between the rows would break,
> leaving an orphan
On 2016/09/07 3:12, Corey Huinker wrote:
> On Fri, Sep 2, 2016 at 5:07 AM, Amit Langote wrote:
>> I am not familiar with win32 stuff too, so I don't have much to say about
>> that. Maybe someone else can chime in to help with that.
>
> The regressions basically *can't* test this because we'd need
On 2016/08/26 15:13, Ashutosh Bapat wrote:
On Fri, Aug 26, 2016 at 11:37 AM, Masahiko Sawada
mailto:sawada.m...@gmail.com>> wrote:
On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat
mailto:ashutosh.ba...@enterprisedb.com>> wrote:
>
>
> On Fri, Aug 26, 2016 at 11:22 AM, Mas
On 7 September 2016 at 04:19, Christoph Berg wrote:
> I like your new version, it's crisp and transports the right message.
OK, updated with Tom's tweaked version of Christoph's wording per
discussion. Thanks all.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Devel
On Wed, Sep 7, 2016 at 12:16 AM, David Steele wrote:
> On 9/1/16 9:53 AM, Peter Eisentraut wrote:
>>
>> On 8/15/16 3:39 PM, David Steele wrote:
>>>
>>> That patch got me thinking about what else could be excluded and after
>>> some investigation I found the following: pg_notify, pg_serial,
>>> pg_
On Tue, Sep 06, 2016 at 01:32:10PM -0400, Christian Convey wrote:
> It sounds like the most useful thing I can do at the moment is perform
> code reviews. I assumed I'd need more experience with the PG code
> base, but I keep on reading that newcomers' reviews are welcome.
> Unless someone has a b
On 9/6/16 7:23 PM, Tom Lane wrote:
> I'm curious where you are on that? I find myself needing to whack around
> this processing in CREATE EXTENSION, but I don't want to create a merge
> problem for you if you're close to committing.
I have committed what I have for now. Thanks.
--
Peter Eisent
On 7 September 2016 at 04:13, Pavel Stehule wrote:
>> Overall, I think this needs to be revised with appropriate comments.
>> Whitespace/formatting needs fixing since it's all over the place.
>> Documentation is insufficient (per notes below).
>
>
> I am not able to write documentation in English
On Wed, Sep 7, 2016 at 1:47 AM, Robert Haas wrote:
> On Mon, Sep 5, 2016 at 8:57 PM, Masahiko Sawada wrote:
>>> What performance difference does this make, in a realistic use case?
>>
>> I have yet to measure performance effect but it would be effect for
>> very large frozen table.
>
> I think if
On Tue, Sep 6, 2016 at 6:53 PM, Craig Ringer
wrote:
> On 7 Sep. 2016 02:14, "Corey Huinker" wrote:
> >
>
> > Having regression tests for this is extremely problematic, because the
> program invoked would need to be an invokable command on any architecture
> supported by postgres. I'm pretty sure
On 7 September 2016 at 10:54, Noah Misch wrote:
> On Tue, Sep 06, 2016 at 01:32:10PM -0400, Christian Convey wrote:
>> It sounds like the most useful thing I can do at the moment is perform
>> code reviews. I assumed I'd need more experience with the PG code
>> base, but I keep on reading that ne
On Fri, Aug 26, 2016 at 7:11 PM, Dilip Kumar wrote:
> I have changed this in attached patch..
>
I reviewed and tested the patch. The changes are fine.
This patch provides better error message compared to earlier.
Marked the patch as "Ready for committer" in commit-fest.
Regards,
Hari Babu
Fuj
On 7 September 2016 at 11:21, Corey Huinker wrote:
> On Tue, Sep 6, 2016 at 6:53 PM, Craig Ringer
> And the TAP test would detect the operating system and know to create an FDW
> that has the PROGRAM value 'cat test_data.csv' on Unix, 'type test_data.csv'
> on windows, and 'type test_data.csv;1'
On Tue, Sep 6, 2016 at 9:46 PM, Amit Langote
wrote:
> On 2016/09/07 3:12, Corey Huinker wrote:
> > On Fri, Sep 2, 2016 at 5:07 AM, Amit Langote wrote:
> >> I am not familiar with win32 stuff too, so I don't have much to say
> about
> >> that. Maybe someone else can chime in to help with that.
>
On Tue, Sep 6, 2016 at 11:24 PM, Craig Ringer
wrote:
> On 7 September 2016 at 11:21, Corey Huinker
> wrote:
> > On Tue, Sep 6, 2016 at 6:53 PM, Craig Ringer <
> craig.rin...@2ndquadrant.com>
>
> > And the TAP test would detect the operating system and know to create an
> FDW
> > that has the PRO
On 7 September 2016 at 11:37, Corey Huinker wrote:
> On Tue, Sep 6, 2016 at 11:24 PM, Craig Ringer
> wrote:
>>
>> On 7 September 2016 at 11:21, Corey Huinker
>> wrote:
>> > On Tue, Sep 6, 2016 at 6:53 PM, Craig Ringer
>> >
>>
>> > And the TAP test would detect the operating system and know to c
Craig Ringer writes:
> On 7 September 2016 at 04:19, Christoph Berg wrote:
>> I like your new version, it's crisp and transports the right message.
> OK, updated with Tom's tweaked version of Christoph's wording per
> discussion. Thanks all.
Pushed with minor stylistic adjustment (narrowing the
Thanks Fujita-san for working on this.
> * with the patch:
> postgres=# explain verbose delete from ft1 using ft2 where ft1.a = ft2.a;
> QUERY PLAN
>
> ---
On Wed, Sep 7, 2016 at 8:52 AM, Haribabu Kommi wrote:
> I reviewed and tested the patch. The changes are fine.
> This patch provides better error message compared to earlier.
>
> Marked the patch as "Ready for committer" in commit-fest.
Thanks for the review !
--
Regards,
Dilip Kumar
Enterpris
On 09/06/2016 10:42 PM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 12:39 PM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 12:08 AM, Heikki Linnakangas wrote:
I attach a patch that changes how we maintain the heap invariant
during tuplesort merging.
Nice!
Thanks!
BTW, the way that k
On Tue, Sep 6, 2016 at 10:28 PM, Heikki Linnakangas wrote:
>> BTW, the way that k-way merging is made more efficient by this
>> approach makes the case for replacement selection even weaker than it
>> was just before we almost killed it.
>
>
> This also makes the replacement selection cheaper, no?
On Tue, Sep 6, 2016 at 10:36 PM, Peter Geoghegan wrote:
> Well, maybe, but the whole idea behind replacement_sort_tuples (by
> which I mean the continued occasional use of replacement selection by
> Postgres) was that we hope to avoid a merge step *entirely*. This new
> merge shift down heap patch
2016-09-07 5:03 GMT+02:00 Craig Ringer :
> On 7 September 2016 at 04:13, Pavel Stehule
> wrote:
>
> >> Overall, I think this needs to be revised with appropriate comments.
> >> Whitespace/formatting needs fixing since it's all over the place.
> >> Documentation is insufficient (per notes below).
On 09/07/2016 12:46 AM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 12:34 AM, Heikki Linnakangas wrote:
Why do we reserve the buffer space for all the tapes right at the beginning?
Instead of the single USEMEM(maxTapes * TAPE_BUFFER_OVERHEAD) callin
inittapes(), couldn't we call USEMEM(TAPE_B
On Tue, Sep 6, 2016 at 10:51 PM, Heikki Linnakangas wrote:
> I still don't get it. When building the initial runs, we don't need buffer
> space for maxTapes yet, because we're only writing to a single tape at a
> time. An unused tape shouldn't take much memory. In inittapes(), when we
> have built
On Tue, Sep 6, 2016 at 10:57 PM, Peter Geoghegan wrote:
> There isn't much point in that, because those buffers are never
> physically allocated in the first place when there are thousands. They
> are, however, entered into the tuplesort.c accounting as if they were,
> denying tuplesort.c the full
On 09/07/2016 09:01 AM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 10:57 PM, Peter Geoghegan wrote:
There isn't much point in that, because those buffers are never
physically allocated in the first place when there are thousands. They
are, however, entered into the tuplesort.c accounting as
On Tue, Sep 6, 2016 at 11:09 PM, Heikki Linnakangas wrote:
>> The big picture here is that you can't only USEMEM() for tapes as the
>> need arises for new tapes as new runs are created. You'll just run a
>> massive availMem deficit, that you have no way of paying back, because
>> you can't "liquid
On 2016/09/07 12:29, Corey Huinker wrote:
> On Tue, Sep 6, 2016 at 9:46 PM, Amit Langote wrote:
>> OK.
> Well...maybe not, depending on what Craig and other can do to educate me
> about the TAP tests.
Sure.
>>> Changing table-level options requires superuser privileges, for security
>>> reasons:
Hi Heikki!
Thank you for reviewing the code, it's always inspiring when a work is
noted (:
>Looking at the code, by "margin", you mean the sum of all "edges", i.e. of
each dimension, of the cube.
Indeed. As far as I remember, this is a terminology of old R*-tree paper.
Now they use the word "perim
>
>
> Suggested comment:
>
> /*
> * This is the parsenode for a column definition in a table-expression
> like XMLTABLE.
> *
> * We can't re-use ColumnDef here; the utility command column
> definition has all the
> * wrong attributes for use in table-expressions and just doesn't make
> sense he
Hi,
I found an useless entry in utf8_to_sjis.map
> {0xc19c, 0x815f},
which is apparently illegal as UTF-8 which postgresql
deliberately refuses. So it should be removed and the attached
patch does that. 0x815f(SJIS) is also mapped from 0xefbcbc(U+FF3C
FULLWIDTH REVERSE SOLIDUS) and it is a righ
On 09/07/2016 09:42 AM, Andrew Borodin wrote:
2. Your algorithm, among loosing some bits of precision (which is
absolutely acceptable - we have like 31 of them and that’s a lot) rely on
false assumption. We compare tuples on page not by MBR of inserted tuple,
but by MBR of tuple on page, which is
101 - 176 of 176 matches
Mail list logo
