On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
>
> On Fri, Nov 22, 2019 at 7:38 PM Amit Khandekar wrote:
> >
> > On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
> >>
> >> I think this is exactly the reason for the problem. In my test [1],
> >> the error "permission denied" occurred when I
Hi,
Attached is the latest patch (v8) to add support for Incremental View
Maintenance (IVM). This patch adds OUTER join support in addition
to the patch (v7) submitted last week in the following post.
On Fri, 22 Nov 2019 15:29:45 +0900 (JST)
Tatsuo Ishii wrote:
> Up to now, IVM supports
On Sun, Nov 17, 2019 at 12:01:08AM +0100, Daniel Gustafsson wrote:
> Fixed by opting for the latter, mostly since it seems best convey what the
> function does.
- recordMultipleDependencies(depender,
- context.addrs->refs, context.addrs->numrefs,
-
On Tue, Nov 26, 2019 at 11:19 AM Amit Khandekar wrote:
>
> On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
> >
> >
> > So, what is the next step here? How about if we somehow check whether
> > the file exists before doing unlink, say by using stat?
> But the thing is, the behaviour is so much
On Mon, Nov 25, 2019 at 11:22 PM vignesh C wrote:
>
> On Sun, Nov 24, 2019 at 5:06 PM Pavel Stehule wrote:
> >
> >
> >
> > ne 24. 11. 2019 v 11:25 odesílatel vignesh C napsal:
> >>
> >> On Sat, Nov 23, 2019 at 4:42 PM Amit Kapila
> >> wrote:
> >> >
> >> > On Fri, Nov 22, 2019 at 3:16 PM
Note that this is the last patch in the series of IVM patches: now we
would like focus on blushing up the patches, rather than adding new
SQL support to IVM, so that the patch is merged into PostgreSQL 13
(hopefully). We are very welcome reviews, comments on the patch.
BTW, the SGML docs in the
> 25 нояб. 2019 г., в 13:03, Michael Paquier написал(а):
>
> On Wed, Nov 06, 2019 at 09:04:25AM +0100, Peter Eisentraut wrote:
>> OK, waiting on some independent verification of benchmark numbers.
>
> Still waiting for these after 19 days, so the patch has been marked as
> returned with
Alvaro Herrera wrote:
> On 2019-Nov-22, Antonin Houska wrote:
>
> > As I pointed out in
> >
> > https://www.postgresql.org/message-id/88183.1574261429%40antos
> >
> > seg.ws_off only replaced readOff in XLogReaderState. So we should only
> > update
> > ws_off where readOff was updated before
On Fri, Nov 08, 2019 at 10:30:39AM +0900, Michael Paquier wrote:
> Per the arguments of upthread, storing a 64-bit XID would require a
> catalog change and you cannot backpatch that. I would suggest to keep
> this patch focused on HEAD, and keep it as an improvement of the
> existing features.
On Wed, Sep 04, 2019 at 06:56:18AM +0200, Antonin Houska wrote:
> This thread started later than our effort but important design questions are
> being discussed there. So far there seems to be no consensus whether
> full-instance encryption should be implemented first, so any effort spent on
>
On Tue, Sep 10, 2019 at 03:47:51PM +0200, Tomas Vondra wrote:
> My feeling is that we should get the BNLJ committed first, and then maybe
> use some of those additional strategies as fallbacks (depending on which
> issues are still unsolved by the BNLJ).
The glacier is melting more. Tomas,
On Mon, Nov 18, 2019 at 05:26:37PM -0800, Peter Geoghegan wrote:
> Attached is v24. This revision doesn't fix the problem with
> xl_btree_insert record bloat, but it does fix the bitrot against the
> master branch that was caused by commit 50d22de9. (This patch has had
> a surprisingly large
On Mon, Nov 25, 2019 at 01:21:27PM +0500, Andrey Borodin wrote:
> I think status Needs Review describes what is going on better. It's
> not like something is awaited from my side.
Indeed. You are right so I have moved the patch instead, with "Needs
review". The patch status was actually
Hi Jeevan,
I have incorporated all the comments in the attached patch. Please review
and let me know your thoughts.
On Thu, Nov 21, 2019 at 2:51 PM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Wed, Nov 20, 2019 at 11:05 AM Suraj Kharage <
> suraj.khar...@enterprisedb.com>
On Wed, Nov 06, 2019 at 09:04:25AM +0100, Peter Eisentraut wrote:
> OK, waiting on some independent verification of benchmark numbers.
Still waiting for these after 19 days, so the patch has been marked as
returned with feedback.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 07, 2019 at 03:41:04PM -0800, Andres Freund wrote:
> The way you do it you need to do it in numerous places, and I'm pretty
> sure you're missing some already. E.g. this will not work to log
> parameters for parametrized statements generated on the server side,
> e.g. for foreign key
On Fri, Nov 22, 2019 at 7:46 PM Peter Eisentraut
wrote:
> On 2019-11-22 07:28, Amit Langote wrote:
> > Hmm, I thought it would be more desirable to not expose a published
> > partitioned table's leaf partitions to a subscriber, because it allows
> > the target table to be defined more flexibly.
>
On Sat, Nov 23, 2019 at 02:35:50AM +0300, Nikita Glukhov wrote:
> Attached 8th version of the patches.
Please be careful here. The CF entry was still marked as waiting on
author, but you sent a new patch series which has not been reviewed.
I have moved this patc to next CF instead.
--
Michael
On Thu, Mar 7, 2019 at 1:26 AM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> On 3/6/19 12:12 PM, Robert Haas wrote:
> > On Tue, Mar 5, 2019 at 5:35 PM Andrew Dunstan
> > wrote:
> >> OK, I think we have agreement on Tom's patch. Do we want to backpatch
> OK, no back-patching it is.
On Fri, Nov 22, 2019 at 4:57 PM Michael Paquier wrote:
> On Fri, Nov 22, 2019 at 02:21:41PM +0900, Amit Langote wrote:
> > Actually, we should also refactor
> > convert_tuples_by_position() to carve out the code that builds the
> > AttrMap into a separate function and move it to attmap.c.
>
> Not
Hi Michael-san,
On Mon, Nov 25, 2019 at 4:13 PM Michael Paquier wrote:
> On Tue, Sep 03, 2019 at 12:37:52AM +0900, Etsuro Fujita wrote:
> > On Wed, Aug 14, 2019 at 11:51 AM Etsuro Fujita
> > wrote:
> >> This is my TODO item for PG13, but I'll give priority to other things
> >> in the next
Hi Amit-san,
Related to the above,
I wonder whether we need the total number of ext stats on
pg_stat_progress_analyze or not. As you might know, there is the same
counter on pg_stat_progress_vacuum and pg_stat_progress_cluster.
For example, index_vacuum_count and index_rebuild_count.
Would it
I looked and found a new "hint".
On Tue, Nov 19, 2019 at 05:57:59AM -0600, Justin Pryzby wrote:
> < 2019-11-15 22:16:07.098 EST >PANIC: could not fsync file
> "base/16491/1731839470.2": No such file or directory
> < 2019-11-15 22:16:08.751 EST >LOG: checkpointer process (PID 27388) was
>
On Mon, Nov 25, 2019 at 04:18:33PM +0900, Michael Paquier wrote:
> Thanks for the review. I'll look at that pretty soon.
Tweaked a bit the comment block added, and committed. Thanks Mark for
the input!
--
Michael
signature.asc
Description: PGP signature
On Tue, Nov 26, 2019 at 5:21 PM Justin Pryzby wrote:
> I looked and found a new "hint".
>
> On Tue, Nov 19, 2019 at 05:57:59AM -0600, Justin Pryzby wrote:
> > < 2019-11-15 22:16:07.098 EST >PANIC: could not fsync file
> > "base/16491/1731839470.2": No such file or directory
> > < 2019-11-15
On Mon, Nov 25, 2019 at 07:11:19PM +0100, Tomas Vondra wrote:
> I'm not planning to do any any immediate work on this, so I agree with
> marking it as RWF. I think Melanie is working on the BNL patch, which
> seems like the right solution.
Thanks, I have switched the patch as returned with
On Mon, Nov 25, 2019 at 9:42 PM Masahiko Sawada
wrote:
>
> On Fri, 22 Nov 2019 at 10:19, Amit Kapila wrote:
> >
> > On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> > wrote:
> > >
> > > I've attached the latest version patch set. The patch set includes all
> > > discussed points regarding
On Fri, Nov 22, 2019 at 7:38 PM Amit Khandekar wrote:
>
> On Fri, 22 Nov 2019 at 4:26 PM, Amit Kapila wrote:
>>
>> I think this is exactly the reason for the problem. In my test [1],
>> the error "permission denied" occurred when I second time executed
>> pg_logical_slot_get_changes() which
Right now JIT provides about 30% improvement of TPC-H Q1 query:
https://www.citusdata.com/blog/2018/09/11/postgresql-11-just-in-time/
I wonder why even at this query, which seems to be ideal use case for
JIT, we get such modest improvement?
I have raised this question several years ago - but
Michael Paquier writes:
> On Sat, Nov 23, 2019 at 02:35:50AM +0300, Nikita Glukhov wrote:
>> Attached 8th version of the patches.
> Please be careful here. The CF entry was still marked as waiting on
> author, but you sent a new patch series which has not been reviewed.
> I have moved this patc
Jobin Augustine writes:
> However, Checking whether the port is open is resulting in error log like:
> 2019-11-25 14:03:44.414 IST [14475] LOG: invalid length of startup packet
> Yes, This is different from "Incomplete startup packet" discussed here.
> Steps to reproduce:
> $ telnet localhost
On Fri, Nov 22, 2019 at 4:38 AM Amit Kapila wrote:
> On Thu, Nov 21, 2019 at 8:32 PM Juan José Santamaría Flecha
> wrote:
> >
> > [1] Win10 (1903) MSVC 19.22.27905
> >
>
> I have tested this on Windows7. I am not sure if it is due to a
> different version of windows, but I think we can't rule
On Wed, 6 Nov 2019 14:34:38 +0100
Peter Eisentraut wrote:
> On 2019-11-05 17:29, Jehan-Guillaume de Rorthais wrote:
> > My best bet so far is that logicalrep_relmap_invalidate_cb is not called
> > after the DDL on the subscriber so the relmap cache is not invalidated. So
> > we end up with
> On Mon, Jun 17, 2019 at 05:31:40AM +0200, Pavel Stehule wrote:
>
> > I like anycompatible and anycompatiblearray.
> >
> > I'll update the patch
> >
>
> and here it is
Thanks for the patch! I've reviewed it a bit, and have a few small
commentaries:
* There are few traces of copy paste in
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
> JIT was not able to significantly (times) increase speed on Q1 query?
> Experiment with VOPS shows that used aggregation algorithm itself is not
> a bottleneck.
> Profile also give no answer for this question.
> Any ideas?
Well, in the
On Sun, Nov 24, 2019 at 3:55 PM vignesh C wrote:
>
> On Sat, Nov 23, 2019 at 4:42 PM Amit Kapila wrote:
> >
>
> > 2.
> > ok( TestLib::pump_until(
> > + $killme,
> > + $psql_timeout,
> > + \$killme_stderr,
> > + qr/FATAL: terminating connection due to administrator command/m
> > + ),
> > + "psql
On 11/11/19 4:28 PM, Mark Dilger wrote:
>
>
>
On further consideration, I'm wondering why we don't just
unconditionally use a closed input pty for all these functions (except
run_log). None of them use any input, and making the client worry
about
whether or not
On Fri, Nov 22, 2019 at 2:49 PM Amit Kapila wrote:
>
> On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> wrote:
> >
> > I've attached the latest version patch set. The patch set includes all
> > discussed points regarding index AM options as well as shared cost
> > balance. Also I added some
On Thu, Nov 21, 2019 at 2:10 PM Amit Kapila wrote:
>
> Thanks for finding the remaining places, the patch looks good to me.
> I hope this covers the entire code. BTW, are you using some script to
> find this or is this a result of manual inspection of code? I have
> modified the commit message
On Fri, 22 Nov 2019 at 10:19, Amit Kapila wrote:
>
> On Wed, Nov 20, 2019 at 11:01 AM Masahiko Sawada
> wrote:
> >
> > I've attached the latest version patch set. The patch set includes all
> > discussed points regarding index AM options as well as shared cost
> > balance. Also I added some test
On Mon, Nov 25, 2019 at 05:33:35PM +0900, Michael Paquier wrote:
On Tue, Sep 10, 2019 at 03:47:51PM +0200, Tomas Vondra wrote:
My feeling is that we should get the BNLJ committed first, and then maybe
use some of those additional strategies as fallbacks (depending on which
issues are still
On Fri, Nov 22, 2019 at 2:29 PM David Steele wrote:
> See:
> https://www.nist.gov/system/files/documents/2017/04/26/lrdc_systems_part2_032713.pdf
> Search for "The maximum block size"
Hmm, so it says: "The maximum block size that can be protected by a
32-bit CRC is 512MB." My problem is that (1)
On 2019-11-24 15:38, David Steele wrote:
On 11/23/19 4:34 PM, Andrew Dunstan wrote:
On 11/23/19 3:13 AM, Tels wrote:
Without the strong hashes it would be pointless to sign the manifest.
I guess I must have missed where we are planning to add a
cryptographic
signature.
I don't think
On Fri, Nov 22, 2019 at 5:15 PM Tels wrote:
> It is related to the number of states...
Thanks for this explanation. See my reply to David where I also
discuss this point.
> However, if you choose a hash, please do not go below SHA-256. Both MD5
> and SHA-1 already had collision attacks, and
On 2019-Nov-25, Antonin Houska wrote:
> Alvaro Herrera wrote:
> > I see no reason to leave ws_off. We can move that to XLogReaderState; I
> > did that here. We also need the offset in WALReadError, though, so I
> > added it there too. Conceptually it seems clearer to me this way.
> >
> >
On Sun, Nov 24, 2019 at 5:06 PM Pavel Stehule wrote:
>
>
>
> ne 24. 11. 2019 v 11:25 odesílatel vignesh C napsal:
>>
>> On Sat, Nov 23, 2019 at 4:42 PM Amit Kapila wrote:
>> >
>> > On Fri, Nov 22, 2019 at 3:16 PM vignesh C wrote:
>> > >
>> > > Thanks for fixing the comments. The changes looks
On Fri, Nov 22, 2019 at 2:02 PM David Steele wrote:
> > Except - and this gets back to the previous point - I don't want to
> > slow down backups by 40% by default. I wouldn't mind slowing them down
> > 3% by default, but 40% is too much overhead. I think we've gotta
> > either the overhead of
On 2019-Nov-11, Alvaro Herrera wrote:
> I'm not sure the proposed changes to gram.y are all that great, though.
Here's a proposed simplification of the gram.y changes. There are two
things here:
1. cosmetic: we don't need the LimitClause struct; we can use just
SelectLimit, and return that
On Sat, Nov 23, 2019 at 4:21 PM Noah Misch wrote:
> I noticed an additional defect:
>
> BEGIN;
> CREATE TABLE t (c) AS SELECT 1;
> CHECKPOINT; -- write and fsync the table's one page
> TRUNCATE t; -- no WAL
> COMMIT; -- no FPI, just the commit record
>
> If we crash after the COMMIT and before
On 11/25/19 5:08 AM, Andrew Dunstan wrote:
On 11/11/19 4:28 PM, Mark Dilger wrote:
On further consideration, I'm wondering why we don't just
unconditionally use a closed input pty for all these functions (except
run_log). None of them use any input, and making the client worry
about
Hi,
We are still on the process to migrate our applications from proprietary RDBMS
to PostgreSQL.
Here is a simple query executed on various systems (real query is different but
this one does not need any data) :
Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 -
(Prior to posting this delta patch, the CF bot appeared happy with this
patch.)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/25/19 1:56 PM, Mark Dilger wrote:
>
>
> On 11/25/19 5:08 AM, Andrew Dunstan wrote:
>>
>> On 11/11/19 4:28 PM, Mark Dilger wrote:
>>>
>>>
>>>
>>
>> On further consideration, I'm wondering why we don't just
>> unconditionally use a closed input pty for all these functions
po 25. 11. 2019 v 20:32 odesílatel Phil Florent
napsal:
> Hi,
>
> We are still on the process to migrate our applications from proprietary
> RDBMS to PostgreSQL.
>
> Here is a simple query executed on various systems (real query is
> different but this one does not need any data) :
>
> Connected
On 10/31/19 7:27 PM, Andrew Dunstan wrote:
> On 10/31/19 6:34 PM, Andrew Dunstan wrote:
>> This time with attachment.
>>
>>
>> On 10/31/19 6:33 PM, Andrew Dunstan wrote:
>>> This patch provides for an sslpassword parameter for libpq, and a hook
>>> that a client can fill in for a callback
Hi,
Thank you, as you mentionned it's not really an interesting real life case
anyway.
Regards,
Phil
De : Pavel Stehule
Envoyé : lundi 25 novembre 2019 21:23
À : Phil Florent
Cc : pgsql-hack...@postgresql.org
Objet : Re: GROUPING SETS and SQL standard
po
On Wed, 2019-11-13 at 16:48 +0100, Lætitia Avrot wrote:
> So after some thoughts I did the minimal patch (for now).
> I corrected documentation for the following tools so that now, using
> connection string
> for Postgres client applications is documented in Postgres:
> - clusterdb
> - pgbench
>
On Mon, Nov 25, 2019 at 03:58:14PM -0500, Robert Haas wrote:
> On Sat, Nov 23, 2019 at 4:21 PM Noah Misch wrote:
> > I noticed an additional defect:
> >
> > BEGIN;
> > CREATE TABLE t (c) AS SELECT 1;
> > CHECKPOINT; -- write and fsync the table's one page
> > TRUNCATE t; -- no WAL
> > COMMIT; --
On Sun, Nov 10, 2019 at 4:35 AM Craig Ringer wrote:
>
> On Mon, 4 Nov 2019 at 12:20, Stephen Frost wrote:
>>
>> Greetings,
>>
>> * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
>> > On 11/1/19 12:58 PM, Robert Haas wrote:
>> > > On Thu, Oct 31, 2019 at 4:58 PM Andrew Dunstan
>> > >
On Wed, Nov 13, 2019 at 12:26 PM Robert Haas wrote:
> On the other hand, 0002 seems like it's pretty clearly a good idea. It
> makes a whole bunch of auxiliary processes use
> procsignal_sigusr1_handler() and those things all get called from
> AuxiliaryProcessMain(), which does ProcSignalInit(),
[ My apologies for being so slow to get back to this ]
John Naylor writes:
> Now that I think of it, the regression in v7 was largely due to the
> fact that the parser has to call the lexer 3 times per string in this
> case, and that's going to be slower no matter what we do.
Ah, of course.
Hi,
I know it's very hard, but is possible. Just someone with the knowledge to do.
Here a proof of concept:
#include
#include
#define MAXPGPATH 256
int main(int argc, char ** argv)
{
chartbsoid[MAXPGPATH];
charstr[MAXPGPATH];
int
Hi Amit-san!
Thanks for your comments!
I have looked at the patch and here are some comments.
I think include_children and current_relid are not enough to
understand the progress of analyzing inheritance trees, because even
with current_relid being updated, I can't tell how many more there
A of () (called grand total in the Standard) is
equivalent to grouping the entire result Table;
If I get it correctly:
select max(dummy) from dual where 0 = 1 group by grouping sets(());
and
select max(dummy) from dual where 0 = 1 ;
should have the same output.
It's the case with
The optimizer cost model usually needs 2 inputs, one is used to represent
data distribution and the other one is used to represent the capacity of
the hardware, like cpu/io let's call this one as system stats.
In Oracle database, the system stats can be gathered with
Phil Florent writes:
> A of () (called grand total in the Standard) is
> equivalent to grouping the entire result Table;
Yeah, I believe so. Grouping by no columns is similar to what happens
if you compute an aggregate with no GROUP BY: the whole table is
taken as one group. If the table is
66 matches
Mail list logo
