Hi,
On 2021-08-23 15:55:03 -0400, alvhe...@alvh.no-ip.org wrote:
> On 2021-Aug-23, Bossart, Nathan wrote:
>
> > Ah, okay. BTW the other changes you mentioned made sense to me.
>
> Thanks. I've pushed this now to all live branches.
While rebasing the aio patchset ontop of HEAD I noticed that
On Sat, Aug 28, 2021 at 3:19 PM Amit Kapila wrote:
>
> On Fri, Aug 27, 2021 at 6:09 PM vignesh C wrote:
> >
> > On Fri, Aug 27, 2021 at 4:57 PM Amit Kapila wrote:
> > >
> > > On Fri, Aug 27, 2021 at 11:43 AM vignesh C wrote:
> > > >
> > > > On Wed, Aug 25, 2021 at 3:07 PM vignesh C wrote:
> >
On 2021-Aug-17, Justin Pryzby wrote:
> I suggest the attached (which partially reverts the revert), to allow showing
> correct data for analyze_count and last_analyzed.
Yeah, that makes sense and my keeping of the pg_stat_all_tables entries
seems pretty useless without this change. I have
> On 28 Aug 2021, at 14:10, Bharath Rupireddy
> wrote:
> It seems there's a redundant assignment statement conn = NULL in
> pg_receivewal's StreamLog function. Attaching a tiny patch herewith.
> Thoughts?
Agreed, while harmless this is superfluous since conn is already set to NULL
after the
Alvaro Herrera writes:
> I think using "%s.%s" as is done everywhere else is pretty much
> pointless. It's not usable as an object identifier, since you have to
> make sure to remove the existing quotes, and unless the names work
> without quotes, you have to add different quotes. So it looks
On 2021-Aug-28, Justin Pryzby wrote:
> Note that check constraints and indexes have the same schema as their table,
> so
> \d doesn't show a schema at all, and quotes the name of the object. That
> distinction may be relevant to how stats objects ended up being quoted like
> this.
Yeah, this
commit a4d75c86bf15220df22de0a92c819ecef9db3849
Author: Tomas Vondra
Date: Fri Mar 26 23:22:01 2021 +0100
Extended statistics on expressions
This commit added to psql/describe.c:
+ /* statistics object name (qualified
with namespace) */
+
> On Aug 28, 2021, at 10:18 AM, Zhihong Yu wrote:
>
> I wonder if the queries with (a=a) or (a complexity to address.
> Has anyone seen such clause in production queries ?
You might expect clauses like WHERE FALSE to be unusual, but that phrase gets
added quite a lot by query generators.
On Sat, Aug 28, 2021 at 9:30 AM Mark Dilger
wrote:
>
>
> > On Aug 28, 2021, at 6:52 AM, Tomas Vondra
> wrote:
> >
> > Part 0003 fixes handling of those clauses so that we don't treat them as
> simple, but it does that by tweaking statext_is_compatible_clause(), as
> suggested by Dean.
>
>
> On Aug 28, 2021, at 6:52 AM, Tomas Vondra
> wrote:
>
> Part 0003 fixes handling of those clauses so that we don't treat them as
> simple, but it does that by tweaking statext_is_compatible_clause(), as
> suggested by Dean.
Function examine_opclause_args() doesn't set issimple to
B: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
Hi,
For 0001-Improve-estimates-for-Var-op-Var-with-the-s-20210828.patch :
+ * form (variable op variable) with the save variable on both sides.
typo: save -> same
Cheers
Hi,
The attached patch series is modified to improve estimates for these
special clauses (Var op Var with the same var on both sides) without
extended statistics. This is done in 0001, and it seems fairly simple
and cheap.
The 0002 part is still the same patch as on 2021/07/20. Part 0003
On 2021-Aug-27, Justin Pryzby wrote:
> I noticed that for \dP+ since 1c5d9270e, regclass is written without
> "pg_catalog." (Alvaro and I failed to notice it in 421a2c483, too).
Oops, will fix shortly.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Hi,
It seems there's a redundant assignment statement conn = NULL in
pg_receivewal's StreamLog function. Attaching a tiny patch herewith.
Thoughts?
Regards,
Bharath Rupireddy.
v1-0001-pg_receivewal-remove-extra-conn-NULL-in-StreamLog.patch
Description: Binary data
On Thu, Aug 26, 2021 at 5:45 PM Ronan Dunklau wrote:
> order to fail early if the replication slot doesn't exist, so please find
> attached v2 for that.
Thanks for the patches. Here are some comments:
1) While the intent of these patches looks good, I have following
concern with new replication
On Sat, Aug 28, 2021 at 4:29 AM Zhihong Yu wrote:
>
>
> On Sat, Aug 28, 2021 at 12:11 AM Dilip Kumar
> wrote:
>
>> On Tue, Aug 24, 2021 at 8:48 PM Robert Haas
>> wrote:
>>
>>> On Fri, Aug 6, 2021 at 4:31 AM Dilip Kumar
>>> wrote:
>>> > Results: (query EXPLAIN ANALYZE SELECT * FROM t;)
>>> >
On Sat, Aug 28, 2021 at 12:11 AM Dilip Kumar wrote:
> On Tue, Aug 24, 2021 at 8:48 PM Robert Haas wrote:
>
>> On Fri, Aug 6, 2021 at 4:31 AM Dilip Kumar wrote:
>> > Results: (query EXPLAIN ANALYZE SELECT * FROM t;)
>> > 1) Non-parallel (default)
>> > Execution Time: 31627.492 ms
>> >
>> > 2)
On Fri, Aug 27, 2021 at 4:27 PM Sadhuprasad Patro wrote:
>
> IMHO, as discussed above, since other databases also have the
> limitation that if you create a multi-column hash index then the hash
> index can not be used until all the key columns are used in the search
> condition. So my point is
Hi,
Review resume:
This patch implements Schema Variables that are database objects that
can hold a single or composite value following the data type used at
variable declaration. Schema variables, like relations, exist within a
schema and their access is controlled via GRANT and REVOKE
On Fri, Aug 27, 2021 at 6:09 PM vignesh C wrote:
>
> On Fri, Aug 27, 2021 at 4:57 PM Amit Kapila wrote:
> >
> > On Fri, Aug 27, 2021 at 11:43 AM vignesh C wrote:
> > >
> > > On Wed, Aug 25, 2021 at 3:07 PM vignesh C wrote:
> > >
> > > I have implemented this in the 0003 patch, I have kept it
Hello David,
round-robin and random make sense. I am wondering how round-robin
would work with -C, though? Would you just reuse the same connection
string as the one chosen at the starting point.
Well, not necessarily, but this is debatable.
My expectation for such a behavior would be
Hi Everyone,
I am Jianhui Lu, a student participating in GSoC 2021, and my project is
'add monitoring to pg_stat_statements to pg_systat'. And following is a
summary of the work I have done during the past 10 weeks.
The first part is about adding new features to pg_systat. The first and
most
On Tue, Aug 24, 2021 at 8:48 PM Robert Haas wrote:
> On Fri, Aug 6, 2021 at 4:31 AM Dilip Kumar wrote:
> > Results: (query EXPLAIN ANALYZE SELECT * FROM t;)
> > 1) Non-parallel (default)
> > Execution Time: 31627.492 ms
> >
> > 2) Parallel with 4 workers (force by setting parallel_tuple_cost
23 matches
Mail list logo
