>
> > 3. Radical alternative: Collapse everything into one new column. We
> > could combine atthasdef and attgenerated and even attidentity into a new
> > column. (Only one of the three can be the case.) This would give
> > client code a clean break, which may or may not be good. The
> >
> Is skip scan only possible for index-only scan?
I haven't see much discussion of this question yet. Is there a
particular reason to lock ourselves into thinking about this only in
an index only scan?
>> I think we can improve this,
>> and the skip scan can be strictly faster than index scan
On Thu, Nov 15, 2018 at 12:38 AM Michael Paquier wrote:
> On Thu, Nov 15, 2018 at 01:38:55PM +0900, Amit Langote wrote:
> > I've fixed 0001 again to re-order the code so that allocations happen the
> > correct context and now tests pass with the rebased patches.
>
> I have been looking at 0001,
On Tue, Oct 30, 2018 at 4:35 AM Peter Eisentraut
wrote:
> 1. (current implementation) New column attgenerated contains 's' for
> STORED, 'v' for VIRTUAL, '\0' for nothing. atthasdef means "there is
> something in pg_attrdef for this column". So a generated column would
> have atthasdef = true,
On Fri, Nov 9, 2018 at 1:32 PM James Coleman wrote:
> Summary:
> Create new guc array_optimization_size_limit and use it to replace
> MAX_SAOP_ARRAY_SIZE in predtest.c.
>
> Status:
> The attached patch applies cleanly to master, builds without error,
> and passes tests locally.
>
Confirmed that
On Thu, Nov 15, 2018 at 10:52 AM Robert Haas wrote:
> I think that the solution that you are proposing sorta sucks, but it's
> better than hacking objsubid to do it, which did in fact pass the
> laugh test, in that I laughed when I read it. :-)
Probably a good idea to get another cup of coffee
Hi,
On 2018-11-15 17:25:21 +0700, John Naylor wrote:
> On 11/15/18, Andres Freund wrote:
> > I've now revised this slightly. genbki.pl now computes the maximum oid
> > explicitly assigned in .dat files, and assignes oids to all 'oid'
> > columns without a value. It does so starting directly at
"Imai, Yoshikazu" writes:
> I changed the state of this patch to "Ready for Committer".
I pushed this with a bit of extra tweaking --- notably, I added an
Assert to ExecFindMatchingSubPlans to guard against the possibility
that someone calls it when the remapping hasn't been done.
I think that
On 2018-Nov-06, Emre Hasegeli wrote:
> > Surely the comment in line 3839 deserves an update :-)
>
> Done.
>
> > This seems good material. I would put the detailed conventions comment
> > separately from the head of the file, like this (where I also changed
> > "Type1 *type1" into "Type1
On Wed, Nov 14, 2018 at 1:28 AM Peter Geoghegan wrote:
> We're already relying on the scan order being in reverse chronological
> order, so we might as well formalize the dependency. I don't think
> that it's possible to sort the pg_depend entries as a way of fixing
> the breakage while avoiding
On Tue, Nov 13, 2018 at 3:40 PM Tomas Vondra
wrote:
> People reading pg_waldump output quickly learn to read the A/B/C format
> and what those fields mean. Breaking that into ts=A db=B relfilenode=C
> does not make that particularly clearer or easier to read. I'd say it'd
> also makes it harder
On Thu, Nov 15, 2018 at 3:03 AM Kuntal Ghosh wrote:
> The test multiple-row-versions is failing because of the
> above-discussed scenario. I've attached the regression diff file and
> the result output file for the same. Here is a brief summary of the
> test w.r.t. heap:
>
> Step 1: T1-> BEGIN;
Hi,
On 2018-11-15 16:39:59 -0600, Justin Pryzby wrote:
> Crash is reproducible but only when JIT=on.
>
> postgresql11-llvmjit-11.1-1PGDG.rhel7.x86_64
>
> [2769871.453033] postmaster[8582]: segfault at 7f083bddb780 ip
> 7f08127e814e sp 7ffe463506e0 error 4
> [2770774.470600]
I wrote:
> Peter Eisentraut writes:
>> On 12/11/2018 20:00, Tom Lane wrote:
>>> Also, even if we had an arguably-better idea, I suspect that there would
>>> always be cases where it didn't work. For example, one idea is to make
>>> a temporary directory under the installation's normal socket
On 25/10/2018 05:43, David Rowley wrote:
> While doing a bit of work on a partitioning patch I noticed that it's
> not really that obvious that there's meant to be exactly 1 item in the
> partexprs List for each zero-valued partattrs element. Some incorrect
> code using these fields was the cause
On Thu, Nov 15, 2018 at 06:03:34PM -0600, Justin Pryzby wrote:
> Verbose plan, munged for brevity/sanity due to joining wide tables, and
> redacted since the view probably has to be considered proprietary. Hopefully
> the remaining bits are still useful. I replaced column names with x.
Actually
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
This patch applies cleanly and works for the case described in the
On Fri, Nov 2, 2018 at 11:17 AM Haribabu Kommi
wrote:
> On Wed, Oct 31, 2018 at 9:34 PM Dmitry Dolgov <9erthali...@gmail.com>
> wrote:
>
>> FYI, alongside with reviewing the code changes I've ran few performance
>> tests
>> (that's why I hit this issue with pgbench in the first place). In case
On 09/10/2018 22:25, David Rowley wrote:
> On 10 October 2018 at 02:38, Peter Eisentraut
> wrote:
>> - * subplan_map[] and subpart_map[] are indexed by partition index (where
>> - * zero is the topmost partition, and non-leaf partitions must come before
>> - * their children). For a leaf
Crash is reproducible but only when JIT=on.
postgresql11-llvmjit-11.1-1PGDG.rhel7.x86_64
[2769871.453033] postmaster[8582]: segfault at 7f083bddb780 ip 7f08127e814e
sp 7ffe463506e0 error 4
[2770774.470600] postmaster[29410]: segfault at 7f0812eeb6c8 ip
7f08127eb4f0 sp
On Thu, Nov 15, 2018 at 02:47:55PM -0800, Andres Freund wrote:
> > (gdb) bt
> > #0 0x7f08127e814e in ?? ()
> > #1 0x in ?? ()
>
> Could you enable jit_debugging_support and reproduce? That should give
> a more useful backtrace.
Core was generated by `postgres: pryzbyj ts
Hi,
On 2018-11-15 18:11:05 -0600, Justin Pryzby wrote:
> On Thu, Nov 15, 2018 at 06:03:34PM -0600, Justin Pryzby wrote:
> > Verbose plan, munged for brevity/sanity due to joining wide tables, and
> > redacted since the view probably has to be considered proprietary.
> > Hopefully
> > the
> On Fri, 27 Apr 2018 at 13:03, Aleksandr Parfenov
> wrote:
>
> Nowadays, phrase operator in Postgres FTS supports only exact match of
> the distance between two words. It is sufficient for a search of
> simple/exact phrases, but in some cases exact distance is unknown and we
> want to words be
On Thu, Nov 15, 2018 at 12:33:35PM -0300, Alvaro Herrera wrote:
> Not sure. Won't that become too verbose? I don't remember needing that
> info for debugging.
Okay, let's drop this idea then. I haven't needed that myself until
now.
--
Michael
signature.asc
Description: PGP signature
Paul Ramsey writes:
> On Fri, Nov 9, 2018 at 1:32 PM James Coleman wrote:
>> Create new guc array_optimization_size_limit and use it to replace
>> MAX_SAOP_ARRAY_SIZE in predtest.c.
> My main comment is that the description of the purpose of the GUC doesn't
> help me understand when or why I
Richard Guo writes:
> On Tue, Nov 13, 2018 at 10:05 AM, Tom Lane wrote:
>> What is the argument that this occurs often enough to be worth expending
>> extra cycles and code space on?
> I am not using an ORM, but just considering maybe it would be better if
> PostgreSQL can do such pull-up.
>
On Fri, Nov 9, 2018 at 4:42 PM David Rowley
wrote:
> On 7 November 2018 at 11:46, Andres Freund wrote:
> > On 2018-11-07 11:40:22 +1300, Thomas Munro wrote:
> >> PostgreSQL likes to probe the size of relations with lseek(SEEK_END) a
> >> lot. For example, a fully prewarmed pgbench -S
On Thu, Nov 15, 2018 at 04:17:51PM -0800, Andres Freund wrote:
> I'm about to commit some changes to 12/master that'd possibly make it
> easier to find issues like this. Is there any chance that it's easier to
> repro this on master than making a reproducible test case?
Yes, very possibly - this
Hi,
On 2018-11-15 17:03:35 -0600, Justin Pryzby wrote:
> On Thu, Nov 15, 2018 at 02:47:55PM -0800, Andres Freund wrote:
> > > (gdb) bt
> > > #0 0x7f08127e814e in ?? ()
> > > #1 0x in ?? ()
> >
> > Could you enable jit_debugging_support and reproduce? That should give
> > a
On Thu, Nov 15, 2018 at 03:14:01PM -0800, Andres Freund wrote:
> Huh, that's the same crash? Because I don't see any evalexpr functions
> in the stack, and without those the above bt should have worked...
TTBOMK it's the same ..
Is it odd if i'm seeing this: (odd because of "ANOTHER") ?
I guess
On Wed, Nov 7, 2018 at 4:39 PM Thomas Munro
wrote:
> On Tue, Sep 25, 2018 at 2:09 PM Thomas Munro
> wrote:
> > Some people like to use DNS SRV records to advertise LDAP servers on
> > their network. Microsoft Active Directory is usually (always?) set up
> > that way. Here is a patch to allow
On Fri, Nov 16, 2018 at 10:57:57AM +0900, Amit Langote wrote:
> Maybe partition_bounds_create() should've had a MemoryContext argument to
> pass it the context we want it to create the PartitionBoundInfo in. That
> way, we can simply pass rd_pdcxt to it and avoid making a copy. As is,
> we're
On Thu, Nov 15, 2018 at 5:18 PM Amit Kapila wrote:
> On Thu, Nov 15, 2018 at 11:38 AM Amit Kapila
> wrote:
> >
> > On Thu, Nov 15, 2018 at 2:05 AM Haribabu Kommi
> wrote:
> > >
> > > On Wed, Nov 14, 2018 at 8:45 PM Amit Kapila
> wrote:
> > >> Apart from the above, I think we should add a test
Alexander Lakhin writes:
> 12.09.2018 10:20, Michael Paquier wrote:
>> On Mon, May 07, 2018 at 01:07:15PM -0400, Tom Lane wrote:
>>> Nah, I disagree with this. To me, the purpose of "make installcheck"
>>> is to verify the correctness of an installation, which I take to include
>>> the client
On 2018-Nov-15, Amit Langote wrote:
> Maybe name it PARTITION_INIT_ALLOCSIZE (dropping the ROUTING from it), or
> PROUTE_INIT_ALLOCSIZE, to make it clear that it's only allocation size?
Here's a proposed delta on v17 0001. Most importantly, I noticed that
the hashed subplans stuff didn't
On Thu, Nov 15, 2018 at 12:14 PM Dilip Kumar wrote:
>
Updated patch (merged latest code from the zheap main branch [1]).
The main chain is related to removing relfilenode and tablespace id
from the undo record and store reloid.
Earlier, we kept it thinking that we will perform rollback without
On Mon, Oct 22, 2018 at 12:14 PM John Naylor wrote:
>
> On 10/16/18, Amit Kapila wrote:
> > I think we can avoid using prevBlockNumber and try_every_block, if we
> > maintain a small cache which tells whether the particular block is
> > tried or not. What I am envisioning is that while finding
On 2018/11/15 22:57, Robert Haas wrote:
> On Thu, Nov 15, 2018 at 12:38 AM Michael Paquier wrote:
>> On Thu, Nov 15, 2018 at 01:38:55PM +0900, Amit Langote wrote:
>>> I've fixed 0001 again to re-order the code so that allocations happen the
>>> correct context and now tests pass with the rebased
On 11/16/18, Andres Freund wrote:
> On 2018-11-15 17:25:21 +0700, John Naylor wrote:
>> I don't see an advantage to having a different range, but maybe it
>> should error out if $maxoid reaches FirstBootstrapObjectId.
>
> Hm. Not sure I really see the point. Note we didn't have that check
>
On Fri, Nov 16, 2018 at 1:00 PM Michael Paquier wrote:
> On Fri, Nov 16, 2018 at 10:57:57AM +0900, Amit Langote wrote:
> > Maybe partition_bounds_create() should've had a MemoryContext argument to
> > pass it the context we want it to create the PartitionBoundInfo in. That
> > way, we can simply
On 2018-Nov-15, Michael Paquier wrote:
> On Wed, Nov 14, 2018 at 11:02:46AM -0300, Alvaro Herrera wrote:
> > Just noticed: ISTM we should also print the infobits_set flags in
> > xl_heap_lock and xl_heap_lock_updated. I can add those.
>
> OK, feel free to do so if you have time, or I can add
On Fri, Nov 16, 2018 at 11:40 AM Alvaro Herrera
wrote:
> On 2018-Nov-15, Amit Langote wrote:
>
> > Maybe name it PARTITION_INIT_ALLOCSIZE (dropping the ROUTING from it), or
> > PROUTE_INIT_ALLOCSIZE, to make it clear that it's only allocation size?
>
> Here's a proposed delta on v17 0001. Most
On Thu, Nov 15, 2018 at 06:12:38PM +0900, Kyotaro HORIGUCHI wrote:
> This patch eliminates unnecessary copying that was done for
> non-continued records. Now the return value of XLogReadRecord
> directly points into page buffer holded in XLogReaderStats. It is
> safe because no caller site uses
On 2018-Nov-15, Laurenz Albe wrote:
> This new option would not only mitigate the long shared_buffers scan,
> it would also get rid of the replication conflict caused by the
> AccessExclusiveLock taken during truncation, which is discussed in
>
At Fri, 26 Oct 2018 14:13:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20181026.141351.09076928.horiguchi.kyot...@lab.ntt.co.jp>
> Thank you for the fix.
>
> At Tue, 23 Oct 2018 17:26:37 +1300, Thomas Munro
> wrote in
>
> > On Thu, Sep 6, 2018 at 9:57 PM Kyotaro HORIGUCHI
>
On Thu, Nov 15, 2018 at 05:14:33PM +0900, Michael Paquier wrote:
> JDBC has its own set of options with targetServerType: master, slave,
> secondary, preferSlave and preferSecondary. What's proposed here is
> preferSlave and what we would miss is slave at the end.
So thinking a couple of extra
Hi.
>> I changed field name from 'reply_time' to 'last_msg_send_time'.
>> Because 'last_msg_send_time' is used in
>> pg_stat_wal_receiver/pg_stat_subsctiption view.
>> I think that field has the same meaning.
>
>I got confused by the field name. If we have 'last_msg_send_time'
>field in
On Wed, Nov 14, 2018 at 5:13 PM Joshua Yanovski
wrote:
>
> This is only a personal anecdote, but from my own experience with
> serializability, this sort of blind update isn't often contended in realistic
> workloads. The reason is that (again, IME), most blind writes are either
> insertions,
At Fri, 26 Oct 2018 11:43:14 +0500, Andrey Lepikhov
wrote in
>
>
> On 26.10.2018 10:33, Kyotaro HORIGUCHI wrote:
> > Hello.
> > At Tue, 23 Oct 2018 10:25:27 +0500, Andrey Lepikhov
> > wrote in
> > <2553f2b0-0e39-eb0e-d382-6c0ed08ca...@postgrespro.ru>
> >>
> >> On 23.10.2018 0:53, Heikki
On Tue, Nov 13, 2018 at 05:54:17PM +1100, Haribabu Kommi wrote:
> On Tue, Nov 13, 2018 at 7:26 AM Laurenz Albe
> wrote:
>> As it is now, the patch doesn't keep two connections open. It remembers
>> the index of the host of the first successful writable connection, but
>> closes the connection,
On Thu, Nov 15, 2018 at 05:02:31PM +0900, myungkyu.lim wrote:
>> I got confused by the field name. If we have 'last_msg_send_time'
>> field in pg_stat_replciation which has information of wal senders
>> users would think it as a time when the wal sender sent a message last
>> time. However values
On Thu, Nov 15, 2018 at 5:27 PM Michael Paquier wrote:
>
> On Thu, Nov 15, 2018 at 05:02:31PM +0900, myungkyu.lim wrote:
> >> I got confused by the field name. If we have 'last_msg_send_time'
> >> field in pg_stat_replciation which has information of wal senders
> >> users would think it as a
On Thu, Nov 15, 2018 at 3:09 AM Kevin Grittner wrote:
>
> On Wed, Nov 14, 2018 at 5:43 AM Joshua Yanovski
> wrote:
>
> > This is only a personal anecdote, but from my own experience with
> > serializability, this sort of blind update isn't often contended in
> > realistic workloads.
>
> > So,
On Thu, Nov 15, 2018 at 2:30 PM Alvaro Herrera wrote:
>
> On 2018-Nov-15, Laurenz Albe wrote:
>
> > This new option would not only mitigate the long shared_buffers scan,
> > it would also get rid of the replication conflict caused by the
> > AccessExclusiveLock taken during truncation, which is
On 11/15/18, Andres Freund wrote:
> I've now revised this slightly. genbki.pl now computes the maximum oid
> explicitly assigned in .dat files, and assignes oids to all 'oid'
> columns without a value. It does so starting directly at the maximum
> value. I personally don't see need to have
At Fri, 02 Nov 2018 14:47:08 +, Nathan Bossart wrote
in <154117002849.5569.14588306221618961668.p...@coridan.postgresql.org>
> One argument for instead checking WAL file existence before calling
> archive_command might be to avoid the increased startup time.
> Granted, any added delay from
Hello, thank you for updating the patch.
>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>At Thu, 4 Oct 2018 04:27:04 +, "Ideriha, Takeshi"
> wrote in
><4E72940DA2BF16479384A86D54D0988A6F1BCB6F@G01JPEXMBKW04>
>> >As a *PoC*, in the attached patch (which applies to current
On Thu, Nov 15, 2018 at 03:41:03PM +0530, Amit Kapila wrote:
> On Thu, Nov 15, 2018 at 2:30 PM Alvaro Herrera
> wrote:
>> FWIW I was just reminded yesterday that the AEL-for-truncation has been
>> diagnosed to be a severe problem in production, and with no other
>> solution in sight, I propose
On 9/27/18 16:59, Jesper Pedersen wrote:
Hi Dmitry,
On 9/15/18 3:52 PM, Dmitry Dolgov wrote:
On Thu, 13 Sep 2018 at 21:36, Alexander Kuzmenkov
wrote:
El 13/09/18 a las 18:39, Jesper Pedersen escribió:
I think we can improve this,
and the skip scan can be strictly faster than index scan
Hi!
Mail.App somehow borken my reponse with , which
is far beyond of my understanding of what is plain text, that's why I'll quote
all my previous message here. Hope this mail client is OK.
14.11.2018, 23:13, "Andrey Borodin" :
> Hi everyone!
>
> I didn't noticed this thread for too long
Tom Lane wrote:
> Pushed. (I simplified the code a bit by using just one state variable,
> and also made the error message more verbose.)
Thanks!
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
On 11/15/18, Amit Kapila wrote:
> Pushed, thanks for working on this.
Thanks for your input.
-John Naylor
2018年11月15日(木) 12:41 Tom Lane :
>
> Kohei KaiGai writes:
> > I noticed buildint2vector / buildoidvector assigns lbound1=0 as default
> > value, but array type shall have lbound1=1 in the default.
> > Is there some reasons for the difference?
>
> Backwards compatibility.
>
Ah, yes, I got the
63 matches
Mail list logo
