David Rowley writes:
> On Fri, 24 Jul 2020 at 16:01, Christophe Pettus wrote:
>> I realize I've never quite known this; where does the planner get the row
>> estimates for an empty table? Example:
> We just assume there are 10 pages if the relation has not yet been
> vacuumed or analyzed. The
> On Jul 24, 2020, at 06:48, Tom Lane wrote:
>
> There's certainly not a lot besides tradition to justify the exact
> numbers used in this case.
Since we already special-case parent tables for partition sets, would a storage
parameter that lets you either tell the planner "no, really, zero
You can benchmark your scenario with and without constraint using a tool
like nancy:
https://gitlab.com/postgres-ai/nancy
it lets you A/B test different configurations with your own scenarios or
using pgbench synthetic workloads.
-Michel
On Wed, Jul 22, 2020 at 9:27 AM Samuel Nelson
wrote:
>
pá 24. 7. 2020 v 16:38 odesílatel Christophe Pettus
napsal:
>
>
> > On Jul 24, 2020, at 06:48, Tom Lane wrote:
> >
> > There's certainly not a lot besides tradition to justify the exact
> > numbers used in this case.
>
> Since we already special-case parent tables for partition sets, would a
> s
I'm trying to understand when RLS select policy is applied so I created the
follow to test but I don't understand why the query filter order is
different for the 2 queries can anyone explain?
CREATE USER bob NOSUPERUSER;
CREATE TABLE t_service (service_type text, service text);
INSERT INTO t_servi
> On Jul 24, 2020, at 12:14, Pavel Stehule wrote:
>
> this application stores some results in tables (as guard against repeated
> calculations). Lot of these tables have zero or one row.
Yes, that's the situation we encountered, too. It's not very common (and even
less common, I would assu
On 7/24/20 12:34 PM, Ted Toth wrote:
I'm trying to understand when RLS select policy is applied so I created
the follow to test but I don't understand why the query filter order is
different for the 2 queries can anyone explain?
The way I see it is:
1) First case. The service column is the on
Ted Toth writes:
> I'm trying to understand when RLS select policy is applied so I created the
> follow to test but I don't understand why the query filter order is
> different for the 2 queries can anyone explain?
The core reason why not is that the ~~ operator isn't considered
leakproof. Plain
On Fri, Jul 24, 2020 at 3:15 PM Tom Lane wrote:
> Ted Toth writes:
> > I'm trying to understand when RLS select policy is applied so I created
> the
> > follow to test but I don't understand why the query filter order is
> > different for the 2 queries can anyone explain?
>
> The core reason why
I have come across a case where PG 12 with default JIT settings makes a
dramatically bad decision. PG11 without JIT, executes the query in <1ms, PG12
with JIT takes 7s--and explain analyze attributes all that time to JIT. (The
plan is the same on both 11 & 12, it's just the JIT.)
It is a compl
Pavel Stehule writes:
> pá 24. 7. 2020 v 16:38 odesílatel Christophe Pettus
> napsal:
>> Since we already special-case parent tables for partition sets, would a
>> storage parameter that lets you either tell the planner "no, really, zero
>> is reasonable here" or sets a minimum number of rows to
I've looked for information on leakproofness of operators but haven't found
anything can you direct me to a source of this information?
On Fri, Jul 24, 2020 at 3:40 PM Ted Toth wrote:
>
> On Fri, Jul 24, 2020 at 3:15 PM Tom Lane wrote:
>
>> Ted Toth writes:
>> > I'm trying to understand when R
On 7/24/20 2:12 PM, Ted Toth wrote:
I've looked for information on leakproofness of operators but haven't
found anything can you direct me to a source of this information?
See here:
https://www.postgresql.org/docs/12/catalog-pg-proc.html
"proleakproof bool The function has no side effect
Ted Toth writes:
> I've looked for information on leakproofness of operators but haven't found
> anything can you direct me to a source of this information?
Operators per se don't have a leakproofness attribute; the function
underlying the operator is what has that property.
On 7/24/20 2:15 PM, Adrian Klaver wrote:
On 7/24/20 2:12 PM, Ted Toth wrote:
I've looked for information on leakproofness of operators but haven't
found anything can you direct me to a source of this information?
See here:
https://www.postgresql.org/docs/12/catalog-pg-proc.html
"proleakproof
> On Jul 24, 2020, at 14:09, Tom Lane wrote:
> Rather than adding another pg_class column, I'm tempted to say that
> vacuum/analyze should set relpages to a minimum of 1, even if the
> relation has zero pages.
If there's not an issue about relpages != actual pages on disk, that certain
seems
On Sat, 25 Jul 2020 at 08:46, Scott Ribe wrote:
> Given the magnitude of the miss in using JIT here, I am wondering: is it
> possible that the planner does not properly take into account the cost of
> JIT'ing a function for multiple partitions? Or is it that the planner doesn't
> have enough in
> On Jul 24, 2020, at 4:26 PM, David Rowley wrote:
>
> It does not really take into account the cost of jitting.
That is what I was missing.
I read about JIT when 12 was pre-release; in re-reading after my post I see
that it does not attempt to estimate JIT cost. And in thinking about it, I
r
David Rowley writes:
> However, for now, you might just want to try raising various jit
> thresholds so that it only is enabled for more expensive plans.
Yeah. I'm fairly convinced that the v12 defaults are far too low,
because we are constantly seeing complaints of this sort.
On Sat, 25 Jul 2020 at 10:37, Tom Lane wrote:
>
> David Rowley writes:
> > However, for now, you might just want to try raising various jit
> > thresholds so that it only is enabled for more expensive plans.
>
> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> because we are c
> On Jul 24, 2020, at 4:37 PM, Tom Lane wrote:
>
> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> because we are constantly seeing complaints of this sort.
They are certainly too low for our case; not sure if for folks who are not
partitioning if they're way too low.
The
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)?
(In the other discussion I started, doing a dump and import of just the tables
involved, onto a system where JIT was inadvertently not worki
Hi,
On 2020-07-24 18:37:02 -0400, Tom Lane wrote:
> David Rowley writes:
> > However, for now, you might just want to try raising various jit
> > thresholds so that it only is enabled for more expensive plans.
>
> Yeah. I'm fairly convinced that the v12 defaults are far too low,
> because we ar
Hi,
On Fri, Jul 24, 2020, at 15:32, Scott Ribe wrote:
> > On Jul 24, 2020, at 4:26 PM, David Rowley wrote:
> >
> > It does not really take into account the cost of jitting.
>
> That is what I was missing.
>
> I read about JIT when 12 was pre-release; in re-reading after my post I
> see that i
so 25. 7. 2020 v 0:49 odesílatel Scott Ribe
napsal:
> 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)?
>
> (In the other discussion I started, doing a dump and import of just the
> table
Hi Experts,
I read this tutorials blog on edb it says vacuum has three phases
1.ingest phase
2.pruning phase
3.cleaning phase
Apart from this blog, no one has explained about the vacuum working
I m getting confusion on each can anyone explain me
https://www.enterprisedb.com/postgres-tutorials/
On Sat, 25 Jul 2020 at 10:42, David Rowley wrote:
>
> On Sat, 25 Jul 2020 at 10:37, Tom Lane wrote:
> >
> > David Rowley writes:
> > > However, for now, you might just want to try raising various jit
> > > thresholds so that it only is enabled for more expensive plans.
> >
> > Yeah. I'm fairly
27 matches
Mail list logo
