On Thu, Jul 2, 2020 at 8:00 PM Bruce Momjian wrote:
> Also, I feel this is all out of scope for PG 13, frankly. I think our
> only option is to revert the hash spill entirely, and return to PG 13
> behavior, if people are too worried about hash performance regression.
But the problem isn't reall
Hi!
On Thu, Jul 2, 2020 at 7:51 PM Mark Dilger wrote:
> I expect these issues to be less than half what you would need to resolve,
> though much of the rest of it is less clear to me.
Thank you for this insightful input. I will think it over.
Mitar
--
http://mitar.tnode.com/
https://twitter
On Thu, Jul 2, 2020 at 7:46 PM Justin Pryzby wrote:
> Thanks for putting it together, I agree that hash_mem seems to be an obvious
> "escape hatch" that generalizes existing GUCs and independently useful.
It is independently useful. It's a natural consequence of "being
honest" about work_mem and
Hi
pá 3. 7. 2020 v 4:39 odesílatel Fujii Masao
napsal:
>
>
> On 2020/07/01 7:37, Peter Geoghegan wrote:
> > On Tue, Jun 30, 2020 at 6:40 AM Fujii Masao
> wrote:
> >> Ants and Andres suggested to replace the spinlock used in pgss_store()
> with
> >> LWLock. I agreed with them and posted the POC
On Thu, Jul 02, 2020 at 03:03:22PM +0200, Daniel Gustafsson wrote:
> AFAICT from the thread there is nothing left of this changeset to consider, so
> I've marked the entry as committed in the CF app. Feel free to update in case
> I've missed something.
A second item discussed in this thread was i
On Thu, Jul 02, 2020 at 10:12:02AM +0200, Petr Jelinek wrote:
> On 02/07/2020 03:58, mich...@paquier.xyz wrote:
>> Adding a new function able to return both fields at the same time does
>> not imply that we'd remove the original one, it just implies that we
>> would be able to retrieve both fields
On 6/22/20 5:11 PM, Ashutosh Bapat wrote:
mailto:a.lepik...@postgrespro.ru>> wrote:
It looks like we call BeginForeignInsert and EndForeignInsert even
though actual copy is performed using BeginForeignCopy, ExecForeignCopy
and EndForeignCopy. BeginForeignInsert constructs the INSERT query whic
On 2020-07-02 16:21, Stephen Frost wrote:
I don't see where I was either proposing that we give up extensibility,
or that we have to include every extension in the core code.
By the way, I have an extension that adds unsigned integer types. I
would argue that that is more frequently requested
> > I think we mark this as rejected.
Stephen Frost wrote:
> The more we reject new things, the less appealing our community ends
> up being.
For what it's worth, I'm not disheartened if my rational patch is
rejected. I can appreciate that postgres wants to avoid what might be
feature creep, espe
On Thu, 2 Jul 2020 at 03:47, Tom Lane wrote:
>
> Amit Khandekar writes:
> > 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.
>
> I took a look at the 0001/0002 patche
On Sat, 20 Jun 2020 at 21:21, Amit Kapila wrote:
>
> On Fri, Jun 19, 2020 at 1:42 PM Andrey V. Lepikhov
> wrote:
> >
> > On 6/19/20 11:48 AM, Amit Kapila wrote:
> > > On Wed, Jun 10, 2020 at 8:36 AM Andrey V. Lepikhov
> > > wrote:
> > >> On 09.06.2020 11:41, Fujii Masao wrote:
> > >>> The patche
On 2020/07/03 13:05, Pavel Stehule wrote:
Hi
pá 3. 7. 2020 v 4:39 odesílatel Fujii Masao mailto:masao.fu...@oss.nttdata.com>> napsal:
On 2020/07/01 7:37, Peter Geoghegan wrote:
> On Tue, Jun 30, 2020 at 6:40 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
>> Ants a
101 - 112 of 112 matches
Mail list logo
