Hi Lu,
On Sat, Mar 27, 2021 at 03:36:25PM +0800, Trafalgar Ricardo Lu wrote:
> Hi,
>
> I am interested in "Add monitoring of pg_stat_statements to pg_systat". I
> have read some code of pg_systat and enabled the pg_stat_statements
> function.
Thanks for your interest!
> I noticed that pg_state_
On 2021-Mar-27, Joel Jacobson wrote:
> If there would be multiple foreign keys on a column we try to follow,
> the query planner would throw an error forcing the user to use explicit joins
> instead.
This seems pretty dangerous -- you just have to create one more FK, and
suddenly a query that wo
On Sat, Mar 27, 2021 at 8:28 PM Joel Jacobson wrote:
> Hi,
>
> The database Neo4j has a language called "Cypher" where one of the key
> selling points is they "don’t need join tables".
>
> Here is an example from
> https://neo4j.com/developer/cypher/guide-sql-to-cypher/
>
> SQL:
>
> SELECT DISTIN
On Fri, Mar 26, 2021, at 14:16, Tom Lane wrote:
> Alvaro Herrera mailto:alvherre%40alvh.no-ip.org>>
> writes:
> > On 2021-Mar-26, Joel Jacobson wrote:
> >> On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> >> I wonder what performance will be like with lots o' objects.
>
> > I guess he is concern
On 3/27/21 7:09 PM, Alvaro Herrera wrote:
> On 2021-Mar-26, Tomas Vondra wrote:
>
>> Hi,
>>
>> I've pushed both the bloom and minmax-multi indexes today.
>
> One thing I've been wondering all along is how useful are these
> BRIN-backed bloom indexes compared to contrib-supplied bloom indexes.
> M
>
> Hey Alvaro,
Well, if it's true that it's translated to the commutator, then I don't
>
think any other code changes are needed.
Great, I will get a patch ready tomorrow. Hopefully we’ll wrap up the GIN
part of the patch soon.
/Mark
On 2021-Mar-27, Mark Rofail wrote:
> Hello Alvaro,
>
> Looking at 0001+0003, I see it claims GIN support for <<@ and @>>, but
> > actually only the former is implemented fully; the latter is missing a
> > strategy number in ginarrayproc.c and pg_amop.dat, and also
> > src/test/regress/sql/gin.sql
On Sat, Mar 27, 2021 at 11:26:47AM -0400, John Naylor wrote:
> On Sat, Mar 27, 2021 at 3:00 AM Noah Misch wrote:
> > Does anyone have a strong opinion on whether to back-patch? I am weakly
> > inclined not to back-patch, because today's behavior might happen to perform
> > better when large_upd_r
>
>
>> Using --functions-only along with --table= does not error out and
> warn the user, instead it creates a dump containing only the SET commands.
> An error similar to using --functions-only along with --data-only seems
> like a good idea.
>
>
Thank you for giving my patch a try.
I added the ne
Hi,
The database Neo4j has a language called "Cypher" where one of the key selling
points is they "don’t need join tables".
Here is an example from https://neo4j.com/developer/cypher/guide-sql-to-cypher/
SQL:
SELECT DISTINCT c.company_name
FROM customers AS c
JOIN orders AS o ON c.customer_id
Hello Alvaro,
Looking at 0001+0003, I see it claims GIN support for <<@ and @>>, but
> actually only the former is implemented fully; the latter is missing a
> strategy number in ginarrayproc.c and pg_amop.dat, and also
> src/test/regress/sql/gin.sql does not test it. I suspect
> ginqueryarrayext
On 2021-Mar-27, alvhe...@alvh.no-ip.org wrote:
> This last one uses libpq_pipeline -t and verifies the output against an
> expected trace file. Applies on top of all the previous patches. I
> attach the whole lot, so that the CF bot has a chance to run it.
All tests pass, but CFbot does not run
Looking at 0001+0003, I see it claims GIN support for <<@ and @>>, but
actually only the former is implemented fully; the latter is missing a
strategy number in ginarrayproc.c and pg_amop.dat, and also
src/test/regress/sql/gin.sql does not test it. I suspect
ginqueryarrayextract needs to be told a
On 2021-Mar-26, alvhe...@alvh.no-ip.org wrote:
> Proposed changes on top of v29.
This last one uses libpq_pipeline -t and verifies the output against an
expected trace file. Applies on top of all the previous patches. I
attach the whole lot, so that the CF bot has a chance to run it.
I did not
I wrote:
> ... which is what forced you to remove or lobotomize several regression
> test cases. Now admittedly, that just moves the state of play for
> cross-partition updates into postgres_fdw partitions from "works
> sometimes" to "works never". But I don't like the idea that we'll
> be taking
On 2021-Mar-26, Tomas Vondra wrote:
> Hi,
>
> I've pushed both the bloom and minmax-multi indexes today.
One thing I've been wondering all along is how useful are these
BRIN-backed bloom indexes compared to contrib-supplied bloom indexes.
My guess is that the BRIN implementation has some advanta
On Wed, Mar 24, 2021 at 08:50:59PM +0100, Peter Eisentraut wrote:
> On 24.03.21 18:58, John Naylor wrote:
> > > As a potential follow-up, should we perhaps add named arguments? That
> > > might make the invocations easier to read, depending on taste.
> >
> > I think it's quite possible some use
On Sat, Mar 27, 2021 at 3:00 AM Noah Misch wrote:
>
> Does anyone have a strong opinion on whether to back-patch? I am weakly
> inclined not to back-patch, because today's behavior might happen to
perform
> better when large_upd_rate-small_ins_rate<0.
It's not a clear case. The present behavior
On 2021-Jan-27, Paul Guo wrote:
> Here is a git diff against the previous patch. I’ll send out the new
> rebased patches after the consensus is reached.
Hmm, can you post a rebased set, where the points under discussion
are marked in XXX comments explaining what the issue is? This thread is
long
On 2021-Feb-02, Drouvot, Bertrand wrote:
> On 12/18/20 12:26 AM, Tom Lane wrote:
> > But any of these options lead to the same question: why stop there?
> > An approach that would actually be defensible, perhaps, is to incorporate
> > this functionality into the dependency mechanism: any time we'
On Sat, Mar 27, 2021 at 6:23 AM Lætitia Avrot
wrote:
> Hello,
>
> You'll find enclosed the first version of my patch.
>
I tested a couple simple use cases. This is great, Thank you!
> I did not include the possibility of using a file to list tables to be
> exported as Tom suggested because I
On 3/27/21 8:22 AM, Lætitia Avrot wrote:
> Hello,
>
> You'll find enclosed the first version of my patch. I did not include
> the possibility of using a file to list tables to be exported as Tom
> suggested because I genuinely think it is a totally different matter.
> It does not mean I'm not ope
Hello,
You'll find enclosed the first version of my patch. I did not include the
possibility of using a file to list tables to be exported as Tom suggested
because I genuinely think it is a totally different matter. It does not
mean I'm not open to the possibility, it just felt weird.
The patch a
On Sat, 2021-03-27 at 00:50 -0700, Noah Misch wrote:
> On Sat, Feb 13, 2021 at 04:56:29AM -0800, Noah Misch wrote:
> > I'm attaching the patch for $SUBJECT, which applies atop the four patches
> > from
> > the two other threads below. For convenience of testing, I've included a
> > rollup patch,
Hi Noah,
Thanks for taking a look at this patch.
>
> In evaluating whether this is a good choice of value, I think about the
> expected page lifecycle. A tuple barely larger than fillfactor (roughly
> len=1+BLCKSZ*fillfactor/100) will start on a roughly-empty page. As long as
> the tuple exist
On Tue, Feb 16, 2021 at 12:01 PM David Rowley wrote:
> On Fri, 12 Feb 2021 at 15:18, Andy Fan wrote:
> >
> > On Fri, Feb 12, 2021 at 9:02 AM David Rowley
> wrote:
> >> The reason I don't really like this is that it really depends where
> >> you want to use RelOptInfo.notnullattrs. If someone w
On Sat, Feb 13, 2021 at 04:56:29AM -0800, Noah Misch wrote:
> I'm attaching the patch for $SUBJECT, which applies atop the four patches from
> the two other threads below. For convenience of testing, I've included a
> rollup patch, equivalent to applying all five patches.
I committed prerequisite
Hi,
I am interested in "Add monitoring of pg_stat_statements to pg_systat". I
have read some code of pg_systat and enabled the pg_stat_statements
function.
I noticed that pg_state_statements has many columns so that can't show in a
single view. Should I divided these columns into diffirent view o
I gather this is important when large_upd_rate=rate(cross-page update bytes
for tuples larger than fillfactor) exceeds small_ins_rate=rate(insert bytes
for tuples NOT larger than fillfactor). That is a plausible outcome when
inserts are rare, and table bloat then accrues at
large_upd_rate-small_in
29 matches
Mail list logo
