On 2018-Nov-12, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 12/11/2018 20:00, Tom Lane wrote:
> >> Also, even if we had an arguably-better idea, I suspect that there would
> >> always be cases where it didn't work. For example, one idea is to make
> >> a temporary directory under the
On 2018-Nov-23, Erik Rijkers wrote:
> gcc-6.3.0 complains about this:
>
> autoprewarm.c: In function ‘autoprewarm_main’:
> autoprewarm.c:210:9: warning: variable ‘rc’ set but not used
> [-Wunused-but-set-variable]
>int rc;
>
> The warning comes only in master.
Yeah, it's fairly new. I
David Rowley writes:
> On Thu, 8 Nov 2018 at 13:14, Tom Lane wrote:
>> There are several things we might do to fix this:
>>
>> 1. Drop the "operation != CMD_DELETE" condition from the above-quoted bit
>> in ExecInitModifyTable. We might be forced into that someday anyway if
>> we want to
On Fri, Nov 23, 2018 at 12:03:27AM +0100, Petr Jelinek wrote:
> On 01/11/2018 01:29, Euler Taveira wrote:
> > Em qua, 28 de fev de 2018 às 20:03, Euler Taveira
> > escreveu:
> >> The attached patches add support for filtering rows in the publisher.
> >>
> > I rebased the patch. I added row
Em sex, 23 de nov de 2018 às 11:40, Petr Jelinek
escreveu:
> But given that this is happening inside output plugin which does not
> have full executor setup and has catalog-only snapshot I am not sure how
> feasible it is to try to merge these two things. As per my previous
> email it's possible
Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
escreveu:
> Firstly, I am not sure if it's wise to allow UDFs in the filter clause
> for the table. The reason for that is that we can't record all necessary
> dependencies there because the functions are black box for parser. That
> means if
Hi hackers,
One of our customers noticed strange thing: time of execution of the
same query is about 25% slower with index only scan, comparing with
indexscan plan
(produced with enable_indexonlyscan = off).
The query is the following:
SELECT
T1._Period,
T1._RecorderTRef,
Hi Andres, Thomas,
Here is a patch for enabling SystemV Shared Memory on AIX, for 64K or bigger
page size, rather than using MMAP shared memory, which is slower on AIX.
We have tested this code with 64K pages and pgbench, on AIX 7.2 TL2 Power 9,
and it provided a maximum of +37% improvement.
Melanie Plageman writes:
> Given that you have addressed all of my feedback and that it's a pretty
> low-risk change, I will change the status to "ready for committer".
Thanks for reviewing!
> Has there been discussion in the past about adding a planner test
> extension similar to those in
Hello,
On 21.11.2018 03:39, Michael Paquier wrote:
I have added a reference to regress-tap in one of the new paragraphs.
Linking the existing stuff to point to "regress" is a separate issue
though, and while pointing to the TAP section is adapted as its
guidelines are rather general, I am not
On 23/11/2018 03:02, Stephen Frost wrote:
> Greetings,
>
> * Euler Taveira (eu...@timbira.com.br) wrote:
>> 2018-02-28 21:54 GMT-03:00 Craig Ringer :
>>> Good idea. I haven't read this yet, but one thing to make sure you've
>>> handled is limiting the clause to referencing only the current tuple
On Fri, Nov 23, 2018 at 3:33 AM David Rowley
wrote:
> On Thu, 22 Nov 2018 at 22:33, Rushabh Lathia
> wrote:
> > CREATE TABLE foo (x int primary key);
> > INSERT INTO foo VALUES (1), (2), (3), (4), (5);
> >
> > CREATE OR REPLACE FUNCTION f1(a int) RETURNS int
> > AS $$
> > BEGIN
> > DELETE FROM
> \dA{f,p,fo,fp,oc}
> Please explain what these are.
We adhere to the following logic
f - families
fo - operators in families
fp - procedures in families
p - access method properties
oc - operator classes
> I think this is two patches -- one being the \dip/\dicp part, the
> other
> the \dA
Alvaro Herrera writes:
> On 12/11/2018 20:00, Tom Lane wrote:
>>> Also, even if we had an arguably-better idea, I suspect that there would
>>> always be cases where it didn't work.
> Surely they can just set TMPDIR if /tmp is not writable? If TMPDIR is
> set and not writable, bark at the user
gcc-6.3.0 complains about this:
autoprewarm.c: In function ‘autoprewarm_main’:
autoprewarm.c:210:9: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
int rc;
The warning comes only in master.
The warnings are a bit annoying; the attached silences them by removing
On 2018-Nov-23, Euler Taveira wrote:
> Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
> escreveu:
> > Won't this leak memory? The list_free only frees the list cells, but not
> > the nodes you stored there before.
>
> Good catch. It should be list_free_deep.
Actually, if the nodes have more
Hi!
> 15 нояб. 2018 г., в 17:30, Andrey Borodin написал(а):
>
> I think I can compose patch for consideration.
I found no practical way to fix concept of "subtree-lock". Pre-locking all left
siblings for cleanup would suffice, but does not look very practical.
GIN Posting tree has no all
On Sun, Nov 11, 2018 at 11:59 PM Tomas Vondra
wrote:
>
> So, what about using FILTER here? We already use it for aggregates when
> filtering rows to process.
>
> i think its good idea and describe its purpose more. Attache is a patch
that use FILTER instead
regards
Surafel
diff --git
On 23/11/2018 19:29, Fabrízio de Royes Mello wrote:
>
> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
> mailto:petr.jeli...@2ndquadrant.com>> wrote:
>>
>> >
>> > If carefully documented I see no problem with it... we already have an
>> > analogous problem with functional indexes.
>>
>> The
On 11/23/18 8:03 PM, Stephen Frost wrote:
> Greetings,
>
> * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
>> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
>> wrote:
If carefully documented I see no problem with it... we already have an
analogous problem with functional
On Sat, Nov 24, 2018 at 4:54 AM REIX, Tony wrote:
> Here is a patch for enabling SystemV Shared Memory on AIX, for 64K or bigger
> page size, rather than using MMAP shared memory, which is slower on AIX.
> We have tested this code with 64K pages and pgbench, on AIX 7.2 TL2 Power 9,
> and it
On Sat, 24 Nov 2018 at 05:25, Tom Lane wrote:
> Now, after more thought, I believe that it's probably impossible
> to have a plan tree in which ExecRelationIsTargetRelation would
> return true at an indexscan node that's not underneath the ModifyTable
> node. What *is* possible is that we have
On Mon, 2 Jul 2018 at 09:37, David Rowley wrote:
> Now that the September 'fest is open for new patches I'm going to move
> this patch over there. This patch has become slightly less important
> than some other stuff, but I'd still like to come back to it.
This had bit-rotted quite a bit, so
On 23/11/2018 17:15, Euler Taveira wrote:
> Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
> escreveu:
>> Firstly, I am not sure if it's wise to allow UDFs in the filter clause
>> for the table. The reason for that is that we can't record all necessary
>> dependencies there because the
Kyotaro HORIGUCHI writes:
> I was reminded that I was often annoyed with identifying the code
> that made a word-completion, by hearing the same complaint from a
> collegue of mine just now.
> Something like the attached that tweaks completion_matches calls
> lets psql emit the line number where
On Fri, 23 Nov 2018 at 07:03, Tomas Vondra wrote:
> On 11/22/18 8:41 AM, David Rowley wrote:
> > ...
> > 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the
> > allocation until it reaches the required size. See how
> > MakeSharedInvalidMessagesArray() does it. Doing it this
On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
wrote:
>
> >
> > If carefully documented I see no problem with it... we already have an
> > analogous problem with functional indexes.
>
> The difference is that with functional indexes you can recreate the
> missing object and everything is okay
Andrew Gierth writes:
> "Tomas" == Tomas Vondra writes:
> Tomas> The important question is - can there be two different encodings
> Tomas> for the same hstore value?
> I was going to say "no", but in fact on closer examination there is an
> edge case caused by the fact that hstoreUpgrade
Greetings,
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
> wrote:
> > > If carefully documented I see no problem with it... we already have an
> > > analogous problem with functional indexes.
> >
> > The difference is that with
On 11/19/18 11:44 AM, Tomas Vondra wrote:
> On 11/19/18 10:28 AM, Masahiko Sawada wrote:
>> On Mon, Nov 19, 2018 at 6:52 AM Tomas Vondra
>> wrote:
>>>
>>> ...
>>>
>>> This does fix the issue, because we still decode the TOAST changes but
>>> there are no data and so
>>>
>>> if
On November 23, 2018 1:10:11 PM PST, David Fetter wrote:
>On Wed, Nov 21, 2018 at 03:47:22PM -0800, Andres Freund wrote:
>> Hi,
>>
>> I feel like we ought to trim the support for a few old versions from
>> pg_upgrade. In my particular case I don't really think it's
>reasonable
>> to test <
On 23/11/2018 17:39, David Fetter wrote:
> On Fri, Nov 23, 2018 at 12:03:27AM +0100, Petr Jelinek wrote:
>> On 01/11/2018 01:29, Euler Taveira wrote:
>>> Em qua, 28 de fev de 2018 às 20:03, Euler Taveira
>>> escreveu:
The attached patches add support for filtering rows in the publisher.
On Wed, Nov 21, 2018 at 03:47:22PM -0800, Andres Freund wrote:
> Hi,
>
> I feel like we ought to trim the support for a few old versions from
> pg_upgrade. In my particular case I don't really think it's reasonable
> to test < 9.0 versions for pg_largeobject_metadata migrations. But I
> think we
On Fri, 23 Nov 2018 at 17:03, David Rowley wrote:
> Here's a patch for that. Parking here until January's commitfest.
And another, now rebased atop of de38ce1b8 (which I probably should
have waited for).
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development,
Here is a patch for my progress on this so far. I'd love some comments
on the general approach, as I've never contributed anything this
involved before. It's not ready for a commitfest, but it would help me
to have some feedback. There are TODO comments with my major
questions.
This patch lets
On 23/11/2018 19:05, Fabrízio de Royes Mello wrote:
> On Fri, Nov 23, 2018 at 3:55 PM Petr Jelinek
> mailto:petr.jeli...@2ndquadrant.com>> wrote:
>>
>> On 23/11/2018 17:15, Euler Taveira wrote:
>> > Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
>> > mailto:petr.jeli...@2ndquadrant.com>>
>
I wrote:
> Andrew Gierth writes:
>> I'm inclined to fix this in hstoreUpgrade rather than complicate
>> hstore_hash with historical trivia. Also there have been no field
>> complaints - I guess it's unlikely that there is much pg 8.4 hstore data
>> in the wild that anyone wants to hash.
>
On 11/23/18 8:14 PM, Petr Jelinek wrote:
> On 23/11/2018 19:29, Fabrízio de Royes Mello wrote:
>>
>> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
>> mailto:petr.jeli...@2ndquadrant.com>> wrote:
>>>
If carefully documented I see no problem with it... we already have an
analogous
On Fri, Nov 23, 2018 at 3:55 PM Petr Jelinek
wrote:
>
> On 23/11/2018 17:15, Euler Taveira wrote:
> > Em qui, 22 de nov de 2018 às 20:03, Petr Jelinek
> > escreveu:
> >> Firstly, I am not sure if it's wise to allow UDFs in the filter clause
> >> for the table. The reason for that is that we
On Fri, Nov 23, 2018 at 2:18 AM Andrey Borodin wrote:
> I found no practical way to fix concept of "subtree-lock". Pre-locking all
> left siblings for cleanup would suffice, but does not look very practical.
> GIN Posting tree has no all useful B-tree inventory like left links and high
> keys
On Fri, Nov 23, 2018 at 11:56 AM John Naylor wrote:
>
> On 11/16/18, Amit Kapila wrote:
>
> >
> > 3.
> > static int fsm_set_and_search(Relation rel, FSMAddress addr, uint16 slot,
> > -uint8 newValue, uint8 minValue);
> > + uint8 newValue, uint8 minValue);
> >
> > This appears to be a
On 11/23/18 12:14 PM, Surafel Temesgen wrote:
>
>
> On Sun, Nov 11, 2018 at 11:59 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
> So, what about using FILTER here? We already use it for aggregates when
> filtering rows to process.
>
> i think its good idea and
On Sat, 24 Nov 2018 at 15:46, Tomas Vondra wrote:
> On 11/24/18 1:56 AM, Edmund Horner wrote:
> > On Fri, 23 Nov 2018 at 07:03, Tomas Vondra
> > wrote:
> >> On 11/22/18 8:41 AM, David Rowley wrote:
> >>> ...
> >>> 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the
> >>>
Hello Alvaro,
Please when you rebase, consider these (minor) changes.
Here it is.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index b5e3a62a33..246944ea79 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -954,6
On Fri, Nov 23, 2018 at 3:41 PM Paul A Jungwirth
wrote:
> Here is a patch for my progress on this so far.
Well this is embarrassing, but my last patch used the mistaken syntax
`PRIMARY KEY (cols, WITHOUT OVERLAPS col)`. Here is a new patch which
uses the correct syntax `PRIMARY KEY (cols, col
On Fri, Nov 23, 2018 at 05:29:00PM +0300, Arthur Zakirov wrote:
> The patch is very useful. Using TAP_TESTS is more convenient and clearer
> than adding wal-check target. Every time I was adding TAP tests for a
> extension I had to remember that I should add wal-check.
wal-check is a custom
On Sat, Nov 24, 2018 at 12:32:36PM +1300, David Rowley wrote:
> On Fri, 23 Nov 2018 at 17:03, David Rowley
> wrote:
> > Here's a patch for that. Parking here until January's commitfest.
>
> And another, now rebased atop of de38ce1b8 (which I probably should
> have waited for).
You have just
On 11/24/18 1:56 AM, Edmund Horner wrote:
> On Fri, 23 Nov 2018 at 07:03, Tomas Vondra
> wrote:
>> On 11/22/18 8:41 AM, David Rowley wrote:
>>> ...
>>> 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the
>>> allocation until it reaches the required size. See how
>>>
48 matches
Mail list logo
