On Tue, 28 Jul 2020 at 15:33, Tom Lane wrote:
>
> David Rowley writes:
> > Maybe this would be better?
>
> > "returns true if jit is enabled and JIT compilation is available in
> > this session (see Chapter 31)."
>
> The general, non-hacker meaning of "jit is enabled" would seem to
> be pretty mu
David Rowley writes:
> Maybe this would be better?
> "returns true if jit is enabled and JIT compilation is available in
> this session (see Chapter 31)."
The general, non-hacker meaning of "jit is enabled" would seem to
be pretty much what this function is already doing; and for that
matter, th
On 2020/07/28 9:08, Ayub M wrote:
> I have a RDS PostgreSQL v11.6 with primary and standby. On the primary,
vacuum/analyze
> were running and pg_stat_all_tables's
last_vacuum/analyze/autovacuum/autoanalyze
> were having values when vacuum/analyze were run.
>
> 1. Switchover to Standby happened,
I have a RDS PostgreSQL v11.6 with primary and standby. On the primary,
vacuum/analyze were running and pg_stat_all_tables's
last_vacuum/analyze/autovacuum/autoanalyze were having values when
vacuum/analyze were run.
1. Switchover to Standby happened, now when I see pg_stat_all_tables (on
the act
On Tue, 28 Jul 2020 at 04:18, Scott Ribe wrote:
>
> > On Jul 25, 2020, at 8:02 AM, Christoph Moench-Tegeder
> > wrote:
> > pg_jit_available() boolean is JIT compilation available in this session
> >
> > https://www.postgresql.org/docs/12/functions-info.html
>
> Thanks, that seems to be exactly
On Tue, 28 Jul 2020 at 11:00, Andres Freund wrote:
>
> On 2020-07-25 10:54:18 -0400, Tom Lane wrote:
> > David Rowley writes:
> > > ... nested at the bottom level join, about 6 joins deep. The lack of
> > > any row being found results in upper level joins not having to do
> > > anything, and the
On 2020-Jul-27, Scott Ribe wrote:
> > On Jul 27, 2020, at 4:00 PM, Alvaro Herrera
> > wrote:
> >
> > I don't quite understand why is it that a table with 1000 partitions
> > means that JIT compiles the thing 1000 times. Sure, it is possible that
> > some partitions have a different column layo
Hi,
On 2020-07-25 10:54:18 -0400, Tom Lane wrote:
> David Rowley writes:
> > ... nested at the bottom level join, about 6 joins deep. The lack of
> > any row being found results in upper level joins not having to do
> > anything, and the majority of the plan is (never executed).
>
> On re-readi
> On Jul 27, 2020, at 4:00 PM, Alvaro Herrera wrote:
>
> I don't quite understand why is it that a table with 1000 partitions
> means that JIT compiles the thing 1000 times. Sure, it is possible that
> some partitions have a different column layout, but it seems an easy bet
> that most cases are
On 2020-Jul-24, Andres Freund wrote:
> I think the issue is more that we need to take into accoutn that the
> overhead of JITing scales ~linearly with the number of JITed
> expressions. And that's not done right now. I've had a patch somewhere
> that had a prototype implementation of changing the
Are you caching the definition some other place in the application stack
and checking it later to compare? If so, I would likely alter the table and
in the same transaction read the definition as recorded in
generation_expression from information_schema.columns. Seems simple enough,
but not sure of
Your question is a bit vague, and your referenced article is quite old. It
doesn't reference pg_stat_progress_vacuum* even despite 9.6 being out for a
while before the article. What version are you using and what questions or
problems do you have that you think are related to vacuum?
*See below
ht
> On Jul 25, 2020, at 8:02 AM, Christoph Moench-Tegeder
> wrote:
>
> ## Scott Ribe (scott_r...@elevated-dev.com):
>
>> So JIT is enabled in your conf, how can you tell from within a client
>> session whether it's actually available (PG compiled with it and
>> compiler available)?
>
> pg_jit_av
Thanks, Christoph! Looks like we'll be able to fix this now that we
know what to do.
Sue
---
Susan E Hurst
Principal Consultant
Brookhurst Data LLC
Email: susan.hu...@brookhurstdata.com
Mobile: 314-486-3261
On 2020-07-26 14:58, Christoph Moench-Teg
> On Jul 25, 2020, at 8:21 AM, Pavel Stehule wrote:
>
>
>
> so 25. 7. 2020 v 14:04 odesÃlatel Scott Ribe
> napsal:
> > On Jul 24, 2020, at 9:55 PM, Pavel Stehule wrote:
> >
> > SELECT * FROM pg_config;
>
> That doesn't tell me whether or not it can actually be used.
>
> It shows if Pos
15 matches
Mail list logo
