On 2020-May-23, Michael Paquier wrote:
> On Thu, May 21, 2020 at 09:32:55AM +0900, Michael Paquier wrote:
> > Thanks for the input, Robert. So, even if we are post-beta1 it looks
> > like there are more upsides than downsides to get that stuff done
> > sooner than later. I propose to get that ap
On Sat, May 23, 2020 at 03:54:30PM -0400, David Gilman wrote:
> I've rounded this patch out with a test and I've set up the commitfest
> website for this thread. The latest patches are attached and I think
> they are ready for review.
Thanks. https://commitfest.postgresql.org/28/2568/
I'm not sur
I've rounded this patch out with a test and I've set up the commitfest
website for this thread. The latest patches are attached and I think
they are ready for review.
On Wed, May 20, 2020 at 11:05 PM David Gilman wrote:
>
> I did some more digging. To keep everyone on the same page there are
> fo
This is a very good improvement! Using information about buffers is my favorite
way to optimize queries.
Not having BUFFERS enabled by default means that in most cases, when asking for
help, people send execution plans without buffers info.
And it's simply in on event to type "(ANALYZE, BUFFERS
Hi
so 23. 5. 2020 v 19:03 odesílatel Amit Khandekar
napsal:
> There are a couple of function call overheads I observed in pl/pgsql
> code : exec_stmt() and exec_cast_value(). Removing these overheads
> resulted in some performance gains.
>
> exec_stmt() :
>
> plpgsql_exec_function() and other to
There are a couple of function call overheads I observed in pl/pgsql
code : exec_stmt() and exec_cast_value(). Removing these overheads
resulted in some performance gains.
exec_stmt() :
plpgsql_exec_function() and other toplevel block executors currently
call exec_stmt(). But actually they don't
On 5/23/20 6:23 PM, Pavel Stehule wrote:
> It's lot of new GUC variables. Isn't better only one that allows list of
> values?
I like this way better.
--
Vik Fearing
On 5/23/20 6:12 PM, Justin Pryzby wrote:
> The patch adds new GUCs for each explain() option.
Thank you for looking at it!
> Would it be better to make a GUC called default_explain_options which might
> say
> "COSTS ON, ANALYZE ON, VERBOSE OFF, BUFFERS TBD, FORMAT TEXT, ..."
> ..and parsed usin
so 23. 5. 2020 v 11:14 odesílatel Vik Fearing
napsal:
> Here is a patch to provide default gucs for EXPLAIN options.
>
> I have two goals with this patch. The first is that I personally
> *always* want BUFFERS turned on, so this would allow me to do it without
> typing it every time.
>
> The sec
> On Fri, May 22, 2020 at 08:40:17AM +1200, David Rowley wrote:
>
> The way I picture the two working together is that the core UniqueKey
> patch adds UniqueKeys to RelOptInfos to allow us to have knowledge
> about what they're unique on based on the base relation's unique
> indexes.
Yep, I'm onbo
On Sat, May 23, 2020 at 11:14:05AM +0200, Vik Fearing wrote:
> Here is a patch to provide default gucs for EXPLAIN options.
>
> I have two goals with this patch. The first is that I personally
> *always* want BUFFERS turned on, so this would allow me to do it without
> typing it every time.
>
>
Le mer. 20 mai 2020 à 16:39, Tom Lane a écrit :
> Guillaume Lelarge writes:
> > Le mer. 20 mai 2020 à 11:26, Daniel Gustafsson a
> écrit :
> >> The question is what --extensions should do: only dump any
> >> extensions that objects in the schema depend on; require a pattern and
> only
> >> dum
Here is a patch to provide default gucs for EXPLAIN options.
I have two goals with this patch. The first is that I personally
*always* want BUFFERS turned on, so this would allow me to do it without
typing it every time.
The second is it would make it easier to change the actual default for
sett
On Fri, May 22, 2020 at 5:11 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > Snowball has made a release! With a tag!
> > I have prepared a patch to update PostgreSQL's copy.
>
> Yeah, this was on my to-do list as well. Thanks for doing it.
>
+1
>
> > I think some consideration could be g
14 matches
Mail list logo
