Hello Alexander,
On Friday, June 7, 2019, Alexander Korotkov
wrote:
> BTW, does this patch checks that temporary table is really orphan?
> AFAICS, user may define some temporary tables in single-user mode
> before running VACUUM.
As far as I remember, the patch checks it.
--
Arthur Zakirov
Hi All,
I was testing bloom indexes today. I understand bloom indexes uses bloom
filters.
As i understand, a bloom filter is a bit array of m bits and a constant "k"
number of hash functions are used to generate hashes for the data. And then
the appropriate bits are set to 1.
I was doing the
On Fri, Jun 07, 2019 at 05:26:32PM -0700, Andres Freund wrote:
> I was more thinking that we'd move the check for orphaned-ness into a
> separate function (maybe IsOrphanedRelation()), and move the code to
> drop orphan relations into a separate function (maybe
> DropOrphanRelations()). That'd
On Fri, Jun 07, 2019 at 09:52:26AM +0200, Daniel Gustafsson wrote:
> While looking at libpq.h I noticed what seems to be a few nitpicks: the GSS
> function prototype isn’t using the common format of having a comment
> specifying
> the file it belongs to; ssl_loaded_verify_locations is defined as
On Fri, Jun 07, 2019 at 08:11:07AM -0400, Stephen Frost wrote:
> I'm pretty sure it ended up there just because that's how things are in
> src/interfaces/libpq. I don't have any objection to moving it, I had
> really just been waiting to see where that thread ended up going.
>
> On a quick look,
Hi,
On 2019-06-07 21:16:12 -0400, Chapman Flack wrote:
> On 06/07/19 21:01, Andres Freund wrote:
> > On 2019-06-07 20:52:38 -0400, Chapman Flack wrote:
> > That'd be a *lot* of additional complexity, and pretty much prohibitive
> > from a performance POV. We'd have to not continue decoding on the
On 06/07/19 21:01, Andres Freund wrote:
> On 2019-06-07 20:52:38 -0400, Chapman Flack wrote:
>> It seems they had ended up designing a whole 'nother "protocol level"
>> involving queries wrapping their results as JSON and an app layer that
>> unwraps again, after trying a simpler first approach
Hi,
On 2019-06-07 20:52:38 -0400, Chapman Flack wrote:
> It seems they had ended up designing a whole 'nother "protocol level"
> involving queries wrapping their results as JSON and an app layer that
> unwraps again, after trying a simpler first approach that was foiled by the
> inability to see
On 06/07/19 19:27, Andres Freund wrote:
> The problem is that I don't recognize a limiting principle:
>
> If we want NOT NULL information for clients, why don't we include the
> underlying types for arrays, and the fields in composite types? What
> about foreign keys? And unique keys?
This
Hi,
On 2019-06-08 08:59:37 +0900, Michael Paquier wrote:
> On Fri, Jun 07, 2019 at 03:58:43PM -0700, Andres Freund wrote:
> > Do we need to move the orphan temp cleanup code into database vacuums or
> > such?
>
> When entering into the vacuum() code path for an autovacuum, only one
> relation at
On Fri, Jun 07, 2019 at 08:55:36AM -0400, Robert Haas wrote:
> Are you talking about the call to ReleaseBulkInsertStatePin, or something
> else?
Yes, I was referring to ReleaseBulkInsertStatePin()
--
Michael
signature.asc
Description: PGP signature
On Fri, Jun 07, 2019 at 03:58:43PM -0700, Andres Freund wrote:
> Do we need to move the orphan temp cleanup code into database vacuums or
> such?
When entering into the vacuum() code path for an autovacuum, only one
relation at a time is processed, and we have prior that extra
processing related
Hi,
On 2019-06-05 19:05:05 -0400, Dave Cramer wrote:
> I am curious why you are "strongly" opposed however. We already have the
> information. Adding doesn't seem onerous.
(thought I'd already replied with this)
The problem is that I don't recognize a limiting principle:
If we want NOT NULL
Hi,
(Moving a part of this discussion to hackers)
In #15840 Thierry had the situation that autovacuum apparently could not
keep up, and he ended up with a wraparound situation. Following the
hints and shutting down the cluster and vacuuming the relevant DB in
single user mode did not resolve the
> On 7 Jun 2019, at 14:43, Robert Haas wrote:
> I think that's probably going in the wrong direction. It's arguable,
> of course. However, it seems to me that there's nothing heap-specific
> about the number 10. It's not computed based on the format of a heap
> page or a heap tuple. It's
On 2019-Jun-07, Robert Haas wrote:
> Yeah, I wondered whether SnapshotNonVacuumable might've been added
> later, but I was too lazy to check the commit log. I'll try coding up
> that approach and see how it looks.
Thanks.
> But do you have any comment on the question of whether this function
>
On Fri, Jun 7, 2019 at 4:30 PM Alvaro Herrera wrote:
> On 2019-Jun-07, Robert Haas wrote:
> > I spent some time today studying heapam_index_build_range_scan and
> > quickly reached the conclusion that it's kind of a mess. At heart
> > it's pretty simple: loop over all the table, check each tuple
On 2019-Jun-07, Robert Haas wrote:
> I spent some time today studying heapam_index_build_range_scan and
> quickly reached the conclusion that it's kind of a mess. At heart
> it's pretty simple: loop over all the table, check each tuple against
> any qual, and pass the visible ones to the
I spent some time today studying heapam_index_build_range_scan and
quickly reached the conclusion that it's kind of a mess. At heart
it's pretty simple: loop over all the table, check each tuple against
any qual, and pass the visible ones to the callback. However, in an
attempt to make it cater
On 2019-May-06, Alvaro Herrera wrote:
> On 2019-May-06, Rushabh Lathia wrote:
>
> > Found another scenario where check constraint is not getting
> > dump for the child table.
>
> You're right, the patched code is bogus; I'm reverting it all for
> today's minors. Thanks for reporting.
Here's
On Fri, Dec 28, 2018 at 11:32 AM Masahiko Sawada wrote:
> On Thu, Dec 27, 2018 at 10:24 PM Alvaro Herrera
> wrote:
> >
> > On 2018-Dec-27, Alexey Kondratov wrote:
> >
> > > To summarize:
> > >
> > > 1) Alvaro and Michael agreed, that REINDEX with tablespace move may be
> > > useful. This is done
On Fri, Mar 8, 2019 at 9:28 AM Michael Paquier wrote:
> On Thu, Mar 07, 2019 at 10:49:29AM -0500, Robert Haas wrote:
> > On Thu, Mar 7, 2019 at 10:24 AM Tom Lane wrote:
> > > So if we think we can invent a "MAGICALLY FIX MY DATABASE" command,
> > > let's do that. But please let's not turn a
On Fri, Jun 7, 2019 at 1:19 PM Andres Freund wrote:
> On 2019-06-07 13:11:21 -0400, Robert Haas wrote:
> > I found what appears to be another typo very nearby. Attached please
> > find v2, fixing both issues.
>
> Hm, I thinks that's fixed already?
Oops, you're right.
--
Robert Haas
On 2019-06-07 13:11:21 -0400, Robert Haas wrote:
> I found what appears to be another typo very nearby. Attached please
> find v2, fixing both issues.
Hm, I thinks that's fixed already?
On Fri, Jun 7, 2019 at 12:52 PM Andres Freund wrote:
> On 2019-06-07 12:37:33 -0400, Robert Haas wrote:
> > TableAmRoutine's index_build_range_scan thinks that parameter #8 is
> > called end_blockno, but table_index_build_range_scan and
> > heapam_index_build_range_scan and BRIN's summarize_range
Hi,
On 2019-06-07 12:37:33 -0400, Robert Haas wrote:
> TableAmRoutine's index_build_range_scan thinks that parameter #8 is
> called end_blockno, but table_index_build_range_scan and
> heapam_index_build_range_scan and BRIN's summarize_range all agree
> that it's the number of blocks to be
Hi,
(David, see bottom if you're otherwise not interested).
On 2019-06-07 09:48:29 -0400, Robert Haas wrote:
> On Sat, Jun 1, 2019 at 3:20 PM Andres Freund wrote:
> > > I'd like to think that the best way to deal with that and reduce the
> > > confusion would be to move anything related to bulk
TableAmRoutine's index_build_range_scan thinks that parameter #8 is
called end_blockno, but table_index_build_range_scan and
heapam_index_build_range_scan and BRIN's summarize_range all agree
that it's the number of blocks to be scanned. I assume that this got
changed at some point while Andres
On 2019-Jun-07, Robert Haas wrote:
> On Fri, Jun 7, 2019 at 8:43 AM Robert Haas wrote:
> > Good catch, and now I notice that the callback is not called
> > estimate_rel_size but relation_estimate_size. Updated patch attached;
> > thanks for the review.
>
> Let's try that one more time, and
Hi,
On 2019-06-07 08:32:37 -0400, Robert Haas wrote:
> On Thu, Jun 6, 2019 at 10:08 PM Michael Paquier wrote:
> > "allvisfrac", "pages" and "tuples" had better be documented about
> > which result they represent.
>
> A lot of the table AM stuff (and the related slot stuff) lacks
> function
On Fri, Jun 7, 2019 at 8:43 AM Robert Haas wrote:
> Good catch, and now I notice that the callback is not called
> estimate_rel_size but relation_estimate_size. Updated patch attached;
> thanks for the review.
Let's try that one more time, and this time perhaps I'll make it compile.
--
Robert
On 6/7/19 9:00 PM, Michael Paquier wrote:
On Fri, Jun 07, 2019 at 03:44:14PM +0900, Masahiko Sawada wrote:
BTW while looking GUC variables defined in trgm_op.c the operators in
each short description seems not correct; there is an extra percent
sign. Should we also fix them?
Both of you are
On Fri, Jun 7, 2019 at 10:17 AM Tomas Vondra
wrote:
> Yes, they could get quite big, and I think you're right we need to
> keep that in mind, because it's on the outer (often quite large) side of
> the join. And if we're aiming to restrict memory usage, it'd be weird to
> just ignore this.
>
>
On Thu, Jun 6, 2019 at 7:31 PM Melanie Plageman
wrote:
> I'm not sure I understand why you would need to compare the original
> tuples to the unmatched tuples file.
I think I was confused. Actually, I'm still not sure I understand this part:
> Then, you iterate again through the outer side a
On Thu, Jun 06, 2019 at 04:33:31PM -0700, Melanie Plageman wrote:
On Tue, Jun 4, 2019 at 12:15 PM Robert Haas wrote:
On Tue, Jun 4, 2019 at 3:09 PM Melanie Plageman
wrote:
> One question I have is, how would the OR'd together bitmap be
> propagated to workers after the first chunk? That is,
On Thu, Jun 06, 2019 at 04:37:19PM -0700, Melanie Plageman wrote:
On Thu, May 16, 2019 at 3:22 PM Thomas Munro wrote:
Admittedly I don't have a patch, just a bunch of handwaving. One
reason I haven't attempted to write it is because although I know how
to do the non-parallel version using a
On Sat, Jun 1, 2019 at 3:20 PM Andres Freund wrote:
> > I'd like to think that the best way to deal with that and reduce the
> > confusion would be to move anything related to bulk inserts into their
> > own header/file, meaning the following set:
> > - ReleaseBulkInsertStatePin
> > -
On Thu, Jun 6, 2019 at 10:29 PM Michael Paquier wrote:
> One thing which is a bit tricky is that for example with COPY FROM we
> have a code path which is able to release a buffer held by the bulk
> insert state.
Are you talking about the call to ReleaseBulkInsertStatePin, or something else?
--
On Thu, Jun 6, 2019 at 2:48 AM Amit Langote wrote:
> Attached is a patch that applies on top of Robert's pdoldcxt-v1.patch,
> which seems to fix this issue for me.
Yeah, that looks right. I think my patch was full of fuzzy thinking
and inadequate testing; thanks for checking it over and coming
On Fri, Jun 7, 2019 at 4:11 AM Daniel Gustafsson wrote:
> Makes sense. Regarding one of the hacks:
>
> +* HACK: if the relation has never yet been vacuumed, use a minimum
> size
> +* estimate of 10 pages. The idea here is to avoid assuming a
> +* newly-created table is
On Thu, Jun 6, 2019 at 10:08 PM Michael Paquier wrote:
> Looks like a neat split.
Thanks.
> "allvisfrac", "pages" and "tuples" had better be documented about
> which result they represent.
A lot of the table AM stuff (and the related slot stuff) lacks
function header comments; I don't like
Hello Amit,
07.06.2019 7:30, Amit Kapila wrote:
> Leaving the changes related to the above two points, I have combined
> all the changes and fixed the things as per my review in the attached
> patch. Alexander, see if you can verify once the combined patch. I
> am planning to commit the attached
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> As mentioned on another thread about test coverage, I have noticed
> that be-gssapi-common.h is not placed at the correct location, even
> its its identication path at the top points to where the file should
> be:
>
On Fri, Jun 07, 2019 at 03:44:14PM +0900, Masahiko Sawada wrote:
> BTW while looking GUC variables defined in trgm_op.c the operators in
> each short description seems not correct; there is an extra percent
> sign. Should we also fix them?
Both of you are right here, and the addition
On Fri, Jun 07, 2019 at 03:30:35PM +0900, Masahiko Sawada wrote:
> Agreed. Please find an attached patch.
Thanks, committed.
--
Michael
signature.asc
Description: PGP signature
On 5/11/19 10:33 PM, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
> http://momjian.us/pgsql_docs/release-12.html
>
> They are committed to git. It includes links to the main docs, where
> appropriate. Our official developer docs will rebuild in a
Hi,
We support ALTER TABLE ADD COLUMN .. GENERATED ALWAYS AS .. but the
doc is missing it. Attached small patch fixes this.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
doc_alter_column_add_generated_column.patch
Description: Binary
> On 6 Jun 2019, at 22:40, Robert Haas wrote:
> It looks to me as though any table AM that uses the relation forks
> supported by PostgreSQL in a more or less normal manner is likely to
> require an implementation of the relation_size callback that is
> identical to the one for heap, and an
Hello.
In guc.c many of the variables are described as "Set_s_ something"
as if the variable name is the omitted subject. A few seem being
wrongly written as "Set something" with the same intention.
Is it useful to unify them to the majority?
wal_level
> gettext_noop("Set the level of
> On 7 Jun 2019, at 06:34, Michael Paquier wrote:
> Any objections to something like the attached?
No objections to moving the file per the patch.
While looking at libpq.h I noticed what seems to be a few nitpicks: the GSS
function prototype isn’t using the common format of having a comment
Hi,
Thanks for the updated patches.
On Fri, Jun 7, 2019 at 2:34 PM David Rowley
wrote:
> Anyway comments welcome. If I had a few more minutes to spare I'd
> have wrapped OLTP in tags, but out of time for now.
Some rewording suggestions.
1.
+...Removal of unwanted data is also a
On Thu, Jun 6, 2019 at 10:19 PM Ian Barwick wrote:
>
> Hi
>
> Commit be8a7a68662 added custom GUC
> "pg_trgm.strict_word_similarity_threshold",
> but omitted to document this in the section "GUC Parameters";
Indeed.
BTW while looking GUC variables defined in trgm_op.c the operators in
each
On Thu, Jun 6, 2019 at 10:21 PM Michael Paquier wrote:
>
> On Thu, Jun 06, 2019 at 05:16:30PM +0900, Masahiko Sawada wrote:
> > So I'd like to propose a small fix for that; move the comment to the
> > right place and add another comment. Please find an attached small
> > patch.
>
> No objections
On Wed, Apr 10, 2019 at 2:19 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:25 PM Kyotaro HORIGUCHI
> wrote:
> >
> > Hello.
> >
> > # Is this still living? I changed the status to "needs review"
> >
> > At Sat, 6 Apr 2019 06:47:32 +0900, Masahiko Sawada
> > wrote in
> >
> > > >
54 matches
Mail list logo
