ew by an expert would be appreciated.
Thanks,
Mat
--
Mat Arye, Technical lead of all thing AI @ Timescale
memory_leak_test.sql
Description: Binary data
memory_leak.patch
Description: Binary data
d a
function to plpy for this?
I've thought about trying to catch the sigint signal from Python, but it
seems that the Python signal machinery would conflict badly with the
Postgres signal machinery.
[1]: https://github.com/timescale/pgai/pull/219
Thanks,
Mat
--
Mat Arye, Technical
Andrey,
Thanks for all your work on this. I think this will be really useful.
>From a user perspective, it would be great to add 2 things:
- A function to extract the timestamp from a V7 UUID (very useful for
defining constraints if partitioning by the uuid-embedded timestamps, for
instance).
- C
Hi All,
I've done upgrade maintenance for multiple extensions now (TimescaleDB
core, Promscale) and I think the original suggestion (wildcard filenames
with control-file switch to enable) here is a good one.
Having one big upgrade file, at its core, enables you to do is move the
logic for "what p
Thanks for taking a look at this Tom.
On Mon, Jun 3, 2019 at 4:07 PM Tom Lane wrote:
> Mat Arye writes:
> > On Fri, May 24, 2019 at 5:05 PM Mat Arye wrote:
> >> 11.3 included some change to partition table planning. Namely
> >> commit 925f46f ("Fix handling o
On Fri, May 24, 2019 at 5:05 PM Mat Arye wrote:
> Hi,
>
> 11.3 included some change to partition table planning. Namely
> commit 925f46f ("Fix handling of targetlist SRFs when scan/join relation is
> known empty.") seems to redo all paths fo
Hi,
11.3 included some change to partition table planning. Namely
commit 925f46f ("Fix handling of targetlist SRFs when scan/join relation is
known empty.") seems to redo all paths for partitioned tables
in apply_scanjoin_target_to_paths. It clears the paths in:
```
if (rel_is_partitioned)
On Tue, Mar 13, 2018 at 6:31 AM, David Rowley
wrote:
> On 13 March 2018 at 11:44, Tom Lane wrote:
> > While it would certainly be nice to have better behavior for that,
> > "add a hook so users who can write C can fix it by hand" doesn't seem
> > like a great solution. On top of the sheer diffi
On Tue, Mar 13, 2018 at 6:56 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Tue, Mar 13, 2018 at 4:14 AM, Tom Lane wrote:
> > Mat Arye writes:
> >> So the use-case is an analytical query like
> >
> >> SELECT date_trunc('hour&
On Mon, Mar 12, 2018 at 2:52 PM, Euler Taveira wrote:
> 2018-03-12 14:03 GMT-03:00 Mat Arye :
> > I have a question about statistics hooks. I am trying to teach the
> planner
> > that when grouping by something like date_trunc('1 day', time) will
> produce
> &g
Hi All,
I have a question about statistics hooks. I am trying to teach the planner
that when grouping by something like date_trunc('1 day', time) will produce
a lot less rows than the number of distinct time values. I want to do that
in an extension. The problem is that I don't see a way to make
t
On Mon, Feb 12, 2018 at 8:41 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2/11/18 23:14, Andres Freund wrote:
> > On 2018-02-11 22:19:30 -0500, Tom Lane wrote:
> >> Not sure what to do about it at this point. We could move that field to
> >> the end for 10.3, leaving 10.2
Hi All,
I am writing to get some advice on extension packaging for minor version
upgrades in Postgres.
We recently found that people who had compiled the TimescaleDB extension
against 10.1 (or installed our binary versions via yum, apt, etc.) had
their extension break when they upgraded to 10.2 d
13 matches
Mail list logo
