legrand legrand wrote:
> set enable_agg_pushdown to true;
> isn't displayed in EXPLAIN (SETTINGS) syntax.
>
>
> The following modification seems to fix that:
>
> src/backend/utils/misc/guc.c
>
> {"enable_agg_pushdown", PGC_USERSET, QUERY_TUNING_METHOD,
>
On Mon, Feb 3, 2020 at 4:22 PM Fujii Masao wrote:
> On 2020/02/01 16:05, Kasahara Tatsuhito wrote:
> > if (scan->rs_base.rs_flags & (SO_TYPE_SEQSCAN | SO_TYPE_SAMPLESCAN))
> > {
> > /*
> > * Ensure a missing snapshot is noticed reliably, even if the
> > *
On Mon, Feb 3, 2020 at 4:28 PM Amit Langote wrote:
> If we are trying to "pg_stop_backup" in phase name, maybe we should
> avoid "pg_start_backup"? Then maybe:
Sorry, I meant to write:
If we are trying to avoid "pg_stop_backup" in phase name, maybe we
should avoid "pg_start_backup"? Then
On Mon, Feb 3, 2020 at 1:17 PM Fujii Masao wrote:
> On 2020/02/02 14:59, Masahiko Sawada wrote:
> > On Fri, 31 Jan 2020 at 02:29, Fujii Masao
> > wrote:
> >> On 2020/01/30 12:58, Kyotaro Horiguchi wrote:
> >>> +WHEN 3 THEN 'stopping backup'::text
> >>>
> >>> I'm not sure, but the
On 2020/02/01 16:05, Kasahara Tatsuhito wrote:
On Thu, Jan 30, 2020 at 1:49 PM Kyotaro Horiguchi
wrote:
At Thu, 30 Jan 2020 13:30:56 +0900, Kasahara Tatsuhito
wrote in
TID scan : yes , seq_scan, ,
Here is wrong, because TID scan came to have SO_TYPE_SEQSCAN flags
On Wed, Jan 29, 2020 at 11:51:10PM +0100, Vik Fearing wrote:
> Thanks for the review!
>
> Would you mind changing the status in the commitfest app?
> https://commitfest.postgresql.org/27/2427/
FWIW, I am not really in favor of changing a default old enough that
it could vote (a45195a).
--
On Fri, Jan 31, 2020 at 02:46:16PM +0900, Michael Paquier wrote:
> Actually, thinking more about it, I'd rather remove this part as well,
> keeping only the change in the third paragraph of this comment block.
I have tweaked a bit the comments in this area, and applied the
patch. I'll begin a
On Mon, Feb 3, 2020 at 2:07 PM Fujii Masao wrote:
> On 2020/02/03 11:05, Amit Langote wrote:
> > Okay. How about the attached?
>
> Thanks for the patches! You added the note just after the description
> about row level security on inherited table, but isn't it better to
> add it before that?
On 2020/02/03 11:05, Amit Langote wrote:
On Fri, Jan 31, 2020 at 9:39 PM Fujii Masao wrote:
On 2020/01/31 13:38, Amit Langote wrote:
On Fri, Jan 31, 2020 at 1:28 AM Fujii Masao wrote:
Fair enough. I finally did back-patch because the behavior is clearly
documented and I failed to hear the
On Fri, Jan 10, 2020 at 10:53 AM Dilip Kumar wrote:
>
> On Mon, Dec 30, 2019 at 3:43 PM Amit Kapila wrote:
> >
> >
> > > 2. During commit time in DecodeCommit we check whether we need to skip
> > > the changes of the transaction or not by calling
> > > SnapBuildXactNeedsSkip but since now we
On 2020/02/02 14:59, Masahiko Sawada wrote:
On Fri, 31 Jan 2020 at 02:29, Fujii Masao wrote:
On 2020/01/30 12:58, Kyotaro Horiguchi wrote:
At Wed, 29 Jan 2020 23:16:08 +0900, Fujii Masao
wrote in
Hi,
pg_basebackup reports the backup progress if --progress option is
specified,
and we
On Sun, Feb 2, 2020 at 12:53 PM Masahiko Sawada
wrote:
> On Wed, 29 Jan 2020 at 17:56, Amit Langote wrote:
> > On Wed, Jan 29, 2020 at 11:29 AM yuzuko wrote:
> > > > How are you going to track changes_since_analyze of partitioned table?
> > > > It's just an idea but we can accumulate
Hi;
So I actually have tried to do carefully encrypted data in Postgres via
pg_crypto. I think the key management problems in PostgreSQL are separable
from table-level encryption. In particular the largest problem right now
with having encrypted attributes is accidental key disclosure. I think
Mark Dilger writes:
> I put the CommandTag enum in src/common because there wasn’t any reason
> not to do so. It seems plausible that frontend test frameworks might want
> access to this enum.
Au contraire, that's an absolutely fundamental mistake. There is
zero chance of this enum holding
On Fri, Jan 31, 2020 at 9:39 PM Fujii Masao wrote:
> On 2020/01/31 13:38, Amit Langote wrote:
> > On Fri, Jan 31, 2020 at 1:28 AM Fujii Masao
> > wrote:
> >> Fair enough. I finally did back-patch because the behavior is clearly
> >> documented and I failed to hear the opinions to object the
On 2020/02/01 18:34, Michael Paquier wrote:
On Thu, Jan 30, 2020 at 04:00:40PM +0900, Michael Paquier wrote:
Anyway, your patch looks like a good idea to me, so let's see if
others have opinions or objections about it.
Seeing nothing, committed v2.
Thanks!
Regards
Ian Barwick
--
Ian
On Sun, Feb 02, 2020 at 10:59:32AM +0100, Pierre Ducroquet wrote:
On Saturday, February 1, 2020 3:24:46 PM CET Tomas Vondra wrote:
On Sat, Feb 01, 2020 at 08:51:04AM +0100, Pierre Ducroquet wrote:
>Hello
>
>At my current job, we have a lot of multi-tenant databases, thus with
>tables containing
Hello all,
Like the title says, using "gin_fuzzy_search_limit" degrades speed when it
has a relatively low setting.
What do I mean by "relatively low"? An example would be when a table with a
GIN index has many millions of rows and a particular keyword search has
1,000,000 possible results
> On 2 Feb 2020, at 18:01, Noah Misch wrote:
>
> Forking thread "logical decoding : exceeded maxAllocatedDescs for .spill
> files" for this side issue:
Thanks, I hadn't seen this.
> On Wed, Jan 08, 2020 at 09:37:04PM -0800, Noah Misch wrote:
>> v10
>> deletes PostgresNode base directories at
Forking thread "logical decoding : exceeded maxAllocatedDescs for .spill
files" for this side issue:
On Wed, Jan 08, 2020 at 09:37:04PM -0800, Noah Misch wrote:
> v10
> deletes PostgresNode base directories at the end of this test file, despite
> the failure[1].
> [1] It has the
[ cc'ing depesz to see what he thinks about this ]
Daniel Gustafsson writes:
> On 1 Feb 2020, at 20:37, Tom Lane wrote:
>> This does lead to some field
>> order rearrangement in text mode, as per the regression test changes,
>> but I think that's not a big deal. (A change can only happen if
Other options are preserved by ALTER (and CLUSTER ON is and most obviously
should be preserved by CLUSTER's rewrite), so I think (SET) CLUSTER should be
preserved by ALTER, too.
As far as I can see, this should be the responsibility of something in the
vicinity of
> On 1 Feb 2020, at 20:37, Tom Lane wrote:
>
> Hamid Akhtar writes:
>> I've reviewed and verified this patch and IMHO, this is ready to be
>> committed.
>
> I took a look at this and I don't think it's really going in the right
> direction. ISTM the clear intent of this code was to attach
On Saturday, February 1, 2020 3:24:46 PM CET Tomas Vondra wrote:
> On Sat, Feb 01, 2020 at 08:51:04AM +0100, Pierre Ducroquet wrote:
> >Hello
> >
> >At my current job, we have a lot of multi-tenant databases, thus with
> >tables containing a tenant_id column. Such a column introduces a severe
>
Hello Tomas,
This patch was marked as ready for committer, but clearly there's an
ongoin discussion about what should be the default behavoir, if this
breaks existing apps etc. So I've marked it as "needs review" and moved
it to the next CF.
The issue is that root (aka Tom) seems to be
Hello Masahiko-san,
I've started a new separate thread from the previous long thread[1]
for internal key management system to PostgreSQL. As I mentioned in
the previous mail[2], we've decided to step back and focus on only
internal key management system for PG13. The internal key management
26 matches
Mail list logo
