On Sat, May 29, 2021, at 22:10, Marko Tiikkaja wrote:
> On Sat, May 29, 2021 at 11:06 PM Joel Jacobson wrote:
>> __
>> Glad you bring this problem up for discussion, something should be done to
>> improve the situation.
>>
>> Personally, as I really dislike search_path and consider using it an
Hello Yura,
didn't measure impact on raw performance yet.
Must be done. There c/should be a guc to control this behavior if the
performance impact is noticeable.
--
Fabien.
> 1. Why do we need scan->rs_nblocks =
>RelationGextNumberOfBlocks(scan->rs_base.rs_rd) for every rescan, which
> looks
>mismatched with the comments along the code. and the comments looks
>reasonable to me.
> 2. For the heap scan after an IndexScan, we don't need to know the heap
>
Hi,
IRIX gave the world O_DIRECT, and then every Unix I've used followed
their lead except Apple's, which gave the world fcntl(fd, F_NOCACHE,
1). From what I could find in public discussion, this API difference
may stem from the caching policy being controlled at the per-file
(vnode) level in old
Good day.
Long time ago I've been played with proprietary "compressed storage"
patch on heavily updated table, and found empty pages (ie cleaned by
vacuum) are not compressed enough.
When table is stress-updated, page for new row versions are allocated
in round-robin kind, therefore some 1GB seg
On Sat, May 29, 2021 at 11:06 PM Joel Jacobson wrote:
> Glad you bring this problem up for discussion, something should be done to
> improve the situation.
>
> Personally, as I really dislike search_path and consider using it an
> anti-pattern.
> I would rather prefer a GUC to hard-code search_pa
Glad you bring this problem up for discussion, something should be done to
improve the situation.
Personally, as I really dislike search_path and consider using it an
anti-pattern.
I would rather prefer a GUC to hard-code search_path to a constant default
value of just ‘public’ that cannot be c
On Tue, May 25, 2021 at 07:13:59PM -0500, Justin Pryzby wrote:
> On Sat, Mar 20, 2021 at 12:16:27PM +1300, Thomas Munro wrote:
> > > > + {
> > > > + {"recovery_init_sync_method", PGC_POSTMASTER,
> > > > ERROR_HANDLING_OPTIONS,
> > > > + gettext_noop("Sets the me
Here's a stripped-down patch that drops the change in what should be
in CALL argument lists, and just focuses on reverting the change in
pg_proc.proargtypes and the consequent mess for ALTER/DROP ROUTINE.
I spent some more effort on the docs, too.
regards, tom lane
diff --
On Sat, May 29, 2021 at 9:08 PM vignesh C wrote:
> One minor comment:
> You can remove the brackets around errcode, You could change:
> + if (localeEl)
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("option \"%s\" specified more than once", defel->defname),
> + parser_errpositio
vignesh C writes:
> I felt inclusion of alias types regpublication and regsubscription will
> help the logical replication users.
This doesn't really seem worth the trouble --- how often would you
use these?
If we had a policy of inventing reg* aliases for every kind of catalog
object, that'd be
On Wed, May 26, 2021 at 7:44 PM Bharath Rupireddy
wrote:
>
> On Wed, May 26, 2021 at 7:18 PM vignesh C wrote:
> > +1 for fixing this issue, we have handled this error in other places.
> > The patch does not apply on head, could you rebase the patch on head
> > and post a new patch.
>
> Thanks. I
Hi,
I felt inclusion of alias types regpublication and regsubscription will
help the logical replication users. This will also help in [1].
The alias types allow simplified lookup of publication oid values for
objects. For example, to examine the pg_publication_rel rows, one could
write:
SELECT pr
Michael Paquier writes:
> On Fri, May 28, 2021 at 11:37:22AM -0400, Tom Lane wrote:
>> It's not clear to me how much of 7ca37fb you're envisioning
>> back-patching in (2). I think it'd be best to back-patch
>> only the addition of pgwin32_setenv, and then let the gssapi
>> code use it. In that w
On 5/29/21 6:29 AM, Amit Kapila wrote:
> On Fri, May 28, 2021 at 5:16 PM Tomas Vondra
> wrote:
>>
>> I wonder if there's a way to free the TOASTed data earlier, instead of
>> waiting until the end of the transaction (as this patch does).
>>
>
> IIUC we are anyway freeing the toasted data at the n
On Fri, May 28, 2021 at 11:37:22AM -0400, Tom Lane wrote:
> There's a lot of value in keeping the branches looking alike.
> On the other hand, 7ca37fb hasn't survived contact with the
> public yet, so I'm a bit nervous about it.
I don't think this set of complications is worth the risk
destabilizi
16 matches
Mail list logo
