Alexander Kuzmenkov writes:
> Recently one of our customers encountered a situation when the planning
> of a particular query takes too long (several minutes) and can't be
> interrupted by pg_terminate_backend(). The query and schema are attached
> (this is generated by Zabbix).
Ugh. I hope t
On Wed, Nov 7, 2018 at 5:46 PM Peter Geoghegan wrote:
> Teodor: Do you think that the issue is fixable? It looks like there
> are serious issues with the design of 218f51584d5 to me. I don't think
> the general "there can't be any inserters at this subtree" thing works
> given that we have to coup
On 2018-11-11 11:29:54 +1300, Thomas Munro wrote:
> On Sat, Nov 10, 2018 at 6:01 PM Andres Freund wrote:
> > I've replaced that with a write barrier / read barrier. I strongly
> > suspect this isn't a problem on the write side in practice (due to the
> > dependent read), but the read side looks m
On Sat, Nov 10, 2018 at 6:01 PM Andres Freund wrote:
> On 2018-10-05 10:29:55 -0700, Andres Freund wrote:
> > - remove the volatiles from GetSnapshotData(). As we've, for quite a
> > while now, made sure both lwlocks and spinlocks are proper barriers
> > they're not needed.
>
> Attached is a p
I've recently been investigating improving our plans for queries like:
SELECT * FROM t WHERE t.foo IN (1, 2..1000);
where the table "t" has a partial index on "foo" where "foo IS NOT NULL".
Currently the planner generates an index [only] scan so long as the number
of
items in the IN expression
On 2018-11-10 20:18:33 +0100, Dmitry Dolgov wrote:
> > On Mon, 2 Jul 2018 at 15:54, Jesper Pedersen
> > wrote:
> >
> > The patch from November 27, 2017 still applies (with hunks),
> >
> > https://commitfest.postgresql.org/18/1166/
> >
> > passes "make check-world" and shows performance improvem
> On Mon, 2 Jul 2018 at 15:54, Jesper Pedersen
> wrote:
>
> The patch from November 27, 2017 still applies (with hunks),
>
> https://commitfest.postgresql.org/18/1166/
>
> passes "make check-world" and shows performance improvements.
>
> Keeping it in "Ready for Committer".
Looks like for some
so 10. 11. 2018 v 19:12 odesílatel Vik Fearing
napsal:
> On 08/11/2018 15:59, Pavel Stehule wrote:
> > Hi
> >
> > We can pass variadic arguments as a array to any variadic function. But
> > some our old variadic functions doesn't supports this feature.
> >
> > We cannot to write
> >
> > SELECT le
> "Vik" == Vik Fearing writes:
>> Attached patch add this possibility to least, greatest functions.
Vik> Is there any particular reason you didn't just make least and
Vik> greatest actual functions?
least() and greatest() have some type unification logic that I don't
think works for actu
On 08/11/2018 15:59, Pavel Stehule wrote:
> Hi
>
> We can pass variadic arguments as a array to any variadic function. But
> some our old variadic functions doesn't supports this feature.
>
> We cannot to write
>
> SELECT least(VARIADIC ARRAY[1,2,3]);
>
> Attached patch add this possibility to
On 09/11/2018 21:37, Daniel Gustafsson wrote:
>> On 8 Aug 2018, at 21:34, Peter Eisentraut
>> wrote:
>>
>> I found some unused and some redundant code in ri_triggers.c that was
>> left around by some previous changes that aimed to optimize away certain
>> trigger invocations. See attached patche
>>Thanks. Initializing the variable seems like the right fix here.
... just had a warning when recompiling from the latest sources on CentOS 7:
labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -O2 -I../../../../src/include
-D_GNU_SOUR
On 9 November 2018 at 21:55, Amit Langote wrote:
> v5-0001-Store-inheritance-root-parent-index-in-otherrel-s.patch
>
> Adds a inh_root_parent field that's set in inheritance child otherrel
> RelOptInfos to store the RT index of their root parent
>
> v5-0002-Overhaul-inheritance-update-delete-p
Hi folks,
I've shared a new patch against 11.0, which seems to work as expected.
(Message ID 5100c2b3-641b-4a35-86d0-12ed2e618...@qqdd.eu.)
While playing with it, it is actually quite easy to get it confused. And so
I wonder — is it actually what we want?
For example, if I refresh including a WH
Hi folks,
I’ve updated this patch against 11.0, and tidied up a few loose ends.
refresh-mv-where-clause-#2.diff
Description: Binary data
d.
> On 5 Nov 2018, at 18:14, John Dent wrote:
>
> Hi folks,
>
> I failed to post a patch on the thread “Delta Materialized View Refreshes?”
> (Message
On 9 November 2018 at 18:45, Amit Langote wrote:
> As long as queries involve tuple routing that touches multiple not yet
> seen partitions, someone doing conflicting operations directly on multiple
> partitions in a transaction will have to be ready to see deadlocks.
> Maybe, we can document that
16 matches
Mail list logo
