On Sun, Dec 22, 2019 at 6:13 AM Tom Lane wrote:
>
> I wrote:
> > As far as point 2 goes, I think this is another outgrowth of the
> > fundamental design error that we load a partitioned rel's partitioning
> > info immediately when the relcache entry is created, rather than later
> > on-demand.
Hello,
regarding my initial post:
> For each insert into a base table there are 3 statements:
> - ANALYZE pg_temp_3.pg_temp_81976
> - WITH updt AS ( UPDATE public.mv1 AS mv SET __ivm_count__ = ...
> - DROP TABLE pg_temp_3.pg_temp_81976
For me there where 3 points to discuss:
- create/drop
On Mon, 23 Dec 2019 at 16:24, Mahendra Singh wrote:
>
> On Fri, 20 Dec 2019 at 17:17, Prabhat Sahu
> wrote:
> >
> > Hi,
> >
> > While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got
> > a server crash on PG Head+V36_patch.
> > Changed configuration parameters and Stack
On Mon, 23 Dec 2019 08:08:53 +
"tsunakawa.ta...@fujitsu.com" wrote:
> From: Yugo Nagata
> > 1. Create a temporary table only once at the first view maintenance in
> > this session. This is possible if we store names or oid of temporary
> > tables used for each materialized view in memory.
Hello.
At Sun, 22 Dec 2019 12:21:00 -0800, Noah Misch wrote in
> On Sun, Dec 22, 2019 at 01:19:30AM -0800, Noah Misch wrote:
> > I am inclined to fix this by decrementing md_num_open_segs before modifying
> > md_seg_fds (second attachment).
>
> That leaked memory, since _fdvec_resize() assumes
On Sun, Dec 22, 2019 at 09:06:41AM +0100, Julien Rouhaud wrote:
On Sun, Dec 22, 2019 at 1:03 AM Tomas Vondra
wrote:
On Sat, Dec 21, 2019 at 04:25:05PM -0500, Tom Lane wrote:
>Nikolay Samokhvalov writes:
>> Here is what ORMs do:
>> select length('SELECT "column_name_1001", "column_name_1002",
On Mon, 23 Dec 2019 12:36:56 +0900
Michael Paquier wrote:
> On Fri, Dec 20, 2019 at 11:14:28AM +0100, Jehan-Guillaume de Rorthais wrote:
> > Yes, that would be great but sadly, it would introduce a regression on
> > various tools relying on them. At least, the one doing "select *" or most
> >
Amit Langote writes:
> On Sun, Dec 22, 2019 at 6:13 AM Tom Lane wrote:
> + * To ensure that it's not leaked completely, re-attach it to the
> + * new reldesc, or make it a child of the new reldesc's rd_pdcxt
> + * in the unlikely event that there is one
Hi all,
Currently, we include the function name string in each FmgrBuiltin
struct, whose size is 24 bytes on 64 bit platforms. As far as I can
tell, the name is usually unused, so the attached (WIP, untested)
patch stores it separately, reducing this struct to 16 bytes.
We can go one step
BTW, I forgot to mention: while I think the patch to forbid pseudotypes
by using CheckAttributeType() can be back-patched, I'm leaning towards
not back-patching the other patch. The situation where we get into
infinite recursion seems not very likely in practice, and it's not
going to cause any
On Mon, Dec 23, 2019 at 1:10 PM Tomas Vondra
wrote:
>
> On Sun, Dec 22, 2019 at 09:06:41AM +0100, Julien Rouhaud wrote:
> >On Sun, Dec 22, 2019 at 1:03 AM Tomas Vondra
> > wrote:
> >>
> >> On Sat, Dec 21, 2019 at 04:25:05PM -0500, Tom Lane wrote:
> >> >> What is the overhead here except the
Hello,
On Thu, Dec 5, 2019 at 11:14 AM Pengzhou Tang wrote:
>
> When hacking the Zedstore, we need to get a more accurate statistic for
> zedstore and we
> faced some restrictions:
> 1) acquire_sample_rows() always use RelationGetNumberOfBlocks to generate
> sampling block
> numbers, this
On Mon, Dec 23, 2019 at 23:49 Tom Lane wrote:
> Amit Langote writes:
> > [1]
> https://www.postgresql.org/message-id/CA%2BHiwqFucUh7hYkfZ6x1MVcs_R24eUfNVuRwdE_FwuwK8XpSZg%40mail.gmail.com
>
> Oh, interesting --- I hadn't been paying much attention to that thread.
> I'll compare your PoC there
On Mon, Dec 23, 2019 at 11:05 AM Mahendra Singh wrote:
> From above example, we can see that after deleting all the tuples from table
> and firing vacuum command, size of table is reduced but size of index
> relation is same as before vacuum.
VACUUM is only able to make existing empty pages in
I wrote:
> One thing I see is that you chose to relocate RelationGetPartitionDesc's
> declaration to partdesc.h, whereupon RelationBuildPartitionDesc doesn't
> have to be exported at all anymore. Perhaps that's a better factorization
> than what I did. It supposes that any caller of
Per a recent thread, these patches remove string literals split with
\-escaped newlines. The first is for the message "materialize mode
required, but it is not allowed in this context" where it's more
prevalent, and we keep perpetuating it; the second is for other
messages, whose bulk is in
On Sun, Dec 22, 2019 at 9:34 PM Michael Paquier wrote:
> Hi all,
>
> I was working on some stuff for table AMs, and I got to wonder it we
> had better rename amapi.h to indexam.h and amapi.c to indexam.c, so as
> things are more consistent with table AM. It is a bit annoying to
> name the files
Amit Langote writes:
> On Mon, Dec 23, 2019 at 23:49 Tom Lane wrote:
>> Oh, interesting --- I hadn't been paying much attention to that thread.
>> I'll compare your PoC there to what I did.
> Actually, I should’ve said that your patch is much better attempt at
> getting this in order, so
g_indg_On Mon, 23 Dec 2019 at 16:11, Amit Kapila
wrote:
>
> On Fri, Dec 20, 2019 at 12:13 PM Masahiko Sawada
> wrote:
> >
> > I've attached the updated version patch that incorporated the all
> > review comments I go so far.
> >
>
> I have further edited the first two patches posted by you. The
On Mon, Dec 23, 2019 at 02:34:34PM +0900, Michael Paquier wrote:
> Hi all,
>
> I was working on some stuff for table AMs, and I got to wonder it we
> had better rename amapi.h to indexam.h and amapi.c to indexam.c, so as
> things are more consistent with table AM. It is a bit annoying to
> name
Hi All,
While doing testing of "parallel vacuum" patch, I found that size of index
relation is not reducing even after deleting all the tuples and firing
vacuum command. I am not sure that this is expected behavior or not. For
reference, below I am giving one example.
postgres=# create table
On Sat, Dec 21, 2019 at 2:10 PM Shawn Debnath wrote:
> On Fri, Dec 20, 2019 at 12:05:34PM +1300, Thomas Munro wrote:
> > I think we should probably just remove the unusual ResetLatch() call,
> > rather than adding a CFI(). See attached. Thoughts?
>
> I agree: removing the ResetLatch() and
From: Tatsuo Ishii
> First of all, we do not think that current approach is the final
> one. Instead we want to implement IVM feature one by one: i.e. we
> start with "immediate update" approach, because it's simple and easier
> to implement. Then we will add "deferred update" mode later on.
I
On Tue, Dec 24, 2019 at 10:59 AM Amit Langote wrote:
> Btw, does the memory leakage fix in this patch address any of the
> pending concerns that were discussed on the "hyrax vs.
> RelationBuildPartitionDesc" thread earlier this year[1]?
>
> [1]
>
On Sun, Dec 22, 2019 at 5:04 PM vignesh C wrote:
>
> Few comments:
> assert variable should be within #ifdef USE_ASSERT_CHECKING in patch
> v2-0008-Add-support-for-streaming-to-built-in-replication.patch:
> + int64 subidx;
> + boolfound = false;
>
On Fri, Dec 20, 2019 at 9:31 AM Amit Khandekar wrote:
> Attached are the patches from master back up to 94 branch.
>
> PG 9.4 and 9.5 have a common patch to be applied :
> pg94_95_use_vfd_for_logrep.patch
> From PG 9.6 onwards, each version has a separate patch.
>
> For PG 9.6, there is no
On Sat, Dec 21, 2019 at 1:25 PM Tom Lane wrote:
> > What is the overhead here except the memory consumption?
>
> The time to copy those strings out of shared storage, any time
> you query pg_stat_activity.
It seems like you're masterminding this, and I don't know why. It
seems unlikely that
At Tue, 10 Dec 2019 16:59:25 +0900 (JST), Kyotaro Horiguchi
wrote in
> shared_buffers=1GB/wal_buffers=16MB(defalut). pgbench -s 20 uses 256MB
> of storage so all of them can be loaded on shared memory.
>
> The attached graph shows larger benefit in TPS drop and latency
> increase for HDD. The
On Mon, Dec 16, 2019 at 11:49:56AM +0900, Michael Paquier wrote:
> On Sun, Dec 15, 2019 at 10:27:12AM -0600, Justin Pryzby wrote:
> > I named it so because it calls both lazy_vacuum_index
> > ("PROGRESS_VACUUM_PHASE_VACUUM_INDEX") and
> > lazy_vacuum_heap("PROGRESS_VACUUM_PHASE_VACUUM_HEAP")
> >
On Thu, Dec 12, 2019 at 3:41 AM Amit Kapila wrote:
> I don't think we have evaluated it yet, but we should do it. The
> point to note is that it is only for the case when wal_level is
> 'logical' (see IsSubTransactionAssignmentPending) in which case we
> already log more WAL, so this might not
On Tue, Dec 24, 2019 at 6:33 AM Tom Lane wrote:
> I wrote:
> > One thing I see is that you chose to relocate RelationGetPartitionDesc's
> > declaration to partdesc.h, whereupon RelationBuildPartitionDesc doesn't
> > have to be exported at all anymore. Perhaps that's a better factorization
> >
On Mon, Dec 23, 2019 at 12:28:36PM -0800, Ashwin Agrawal wrote:
> I had raised the same earlier and [1] has response from Andres, which was
> "We probably should rename it, but not in 12..."
>
> [1]
> https://www.postgresql.org/message-id/20190508215135.4eljnhnle5xp3jwb%40alap3.anarazel.de
Okay,
On Sun, Dec 22, 2019 at 8:32 PM Rushabh Lathia wrote:
> Agree, that performance won't be a problem, but that will be bit confusing
> to the user. As at the start user providing the manifest-checksum (assume
> that user-provided CRC32C) and at the end, user will find the SHA256
> checksum string
On Fri, 20 Dec 2019 at 22:30, Amit Kapila wrote:
>
> On Fri, Dec 20, 2019 at 11:47 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 2 Dec 2019 at 17:32, Dilip Kumar wrote:
> > >
> > > On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier
> > > wrote:
> > > >
> > > > On Fri, Nov 22, 2019 at 01:18:11PM
On Fri, Dec 20, 2019 at 01:08:47AM +, Smith, Peter wrote:
> I updated the most recent patch (_5 from Michael) so it now has your
> suggested error message rewording.
Hmm. Based on the last messages, and this one in particular:
On Tue, Dec 24, 2019 at 12:00 AM Tom Lane wrote:
> BTW, I forgot to mention: while I think the patch to forbid pseudotypes
> by using CheckAttributeType() can be back-patched, I'm leaning towards
> not back-patching the other patch. The situation where we get into
> infinite recursion seems not
On Fri, Dec 06, 2019 at 02:09:05PM +0900, Michael Paquier wrote:
> I guess that we should do that at the end of the day. A lookup at the
> in-core tools I see three areas which stand out compared to the rest:
> - pg_waldump, and attached is a patch for it.
Okay, I have committed this one.
--
On Fri, Dec 6, 2019 at 11:51 PM Julien Rouhaud wrote:
>
> Hi,
>
> This topic was discussed several times, with the most recent
> discussions found at [1] and [2]. Based on those discussions, my
> understanding is that the current approach in BASE_BACKUP has too many
> drawbacks and we should
On Mon, Dec 23, 2019 at 07:24:28PM -0600, Justin Pryzby wrote:
> I renamed.
Hmm. I have found what was partially itching me for patch 0002, and
that's actually the fact that we don't do the error reporting for heap
within lazy_vacuum_heap() because the code relies too much on updating
two
On Mon, 23 Dec 2019 at 19:41, Amit Kapila wrote:
>
> On Fri, Dec 20, 2019 at 12:13 PM Masahiko Sawada
> wrote:
> >
> > I've attached the updated version patch that incorporated the all
> > review comments I go so far.
> >
>
> I have further edited the first two patches posted by you. The
>
On Sat, Dec 21, 2019 at 10:28 AM Tom Lane wrote:
> I just had to retrieve my jaw from the floor after reading this
> bit in RelationBuildPartitionDesc:
>
> * The system cache may be out of date; if so, we may find no pg_class
> * tuple or an old one where relpartbound is NULL.
On Tue, Dec 24, 2019 at 12:08 PM Masahiko Sawada
wrote:
>
>
> The first patches look good to me. I'm reviewing other patches and
> will post comments if there is.
>
Okay, feel free to address few comments raised by Mahendra along with
whatever you find.
--
With Regards,
Amit Kapila.
On Tue, Dec 24, 2019 at 4:23 AM Masahiko Sawada wrote:
>
> On Fri, Dec 6, 2019 at 11:51 PM Julien Rouhaud wrote:
> >
> > This brings the second consideration: how to report the list corrupted
> > blocks to end users. As I said this is for now returned via the SRF,
> > but this is clearly not
At Sat, 21 Dec 2019 01:18:24 +, "Bossart, Nathan"
wrote in
> On 12/18/19, 8:34 AM, "Bossart, Nathan" wrote:
> > On 12/17/19, 2:26 AM, "Kyotaro Horiguchi" wrote:
> >> If so, we could amend also that case by marking the last segment as
> >> .ready when XLogWrite writes the first bytes of
On Mon, 23 Dec 2019 03:41:18 -0700 (MST)
legrand legrand wrote:
> Hello,
> regarding my initial post:
>
> > For each insert into a base table there are 3 statements:
> > - ANALYZE pg_temp_3.pg_temp_81976
> > - WITH updt AS ( UPDATE public.mv1 AS mv SET __ivm_count__ = ...
> > - DROP TABLE
On Mon, Dec 23, 2019 at 11:02 PM Mahendra Singh wrote:
>
> 5. I am not sure that I am right but I can see that we are not consistent
> while ending the single line comments.
>
> I think, if single line comment is started with "upper case letter", then we
> should not put period(dot) at the end
On Tue, 24 Dec 2019 at 15:44, Amit Kapila wrote:
>
> On Tue, Dec 24, 2019 at 12:08 PM Masahiko Sawada
> wrote:
> >
> >
> > The first patches look good to me. I'm reviewing other patches and
> > will post comments if there is.
> >
Oops I meant first "two" patches look good to me.
>
> Okay, feel
From: Yugo Nagata
> On Mon, 23 Dec 2019 08:08:53 +
> "tsunakawa.ta...@fujitsu.com" wrote:
> > How about unlogged tables ? I thought the point of using a temp table is to
> avoid WAL overhead.
>
> Hmm... this might be another option. However, if we use unlogged tables,
> we will need to
From: Yugo Nagata
> 1. Create a temporary table only once at the first view maintenance in
> this session. This is possible if we store names or oid of temporary
> tables used for each materialized view in memory. However, users may
> access to these temptables whenever during the session.
>
>
Hi,
On 2019-12-07 11:07:04 +0530, Amit Kapila wrote:
> On Sat, Dec 7, 2019 at 5:42 AM Andres Freund wrote:
> >
> > Tom, I seem to recall a recent thread of yours discussing a different
> > approach to truncation. I wonder if there's some intersection with
> > that. But unfortunately my search
>> But if you want to get always up-to-data you need to pay the cost for
>> REFRESH MATERIALIZED VIEW. IVM gives a choice here.
>
> Thank you, that clarified to some extent. What kind of data do you think of
> as an example?
>
> Materialized view reminds me of the use in a data warehouse.
51 matches
Mail list logo
