> 13 мая 2019 г., в 12:14, Michael Paquier написал(а):
>
>> Currently we test mostly decompression improvements against two WALs
>> and one data file taken from pgbench-generated database. Any
>> suggestion on more relevant data payloads are very welcome.
>
> Text strings made of random data
Hi all,
When we build hash table for a hash join node etc., we split tuples into
different hash buckets. Since tuples could not all be held in memory.
Postgres splits each bucket into batches, only the current batch of bucket
is in memory while other batches are written to disk.
During ExecHashTa
On Mon, May 13, 2019 at 11:36 PM Robert Haas wrote:
>
> On Sun, May 12, 2019 at 2:15 AM Dilip Kumar wrote:
> > I have removed some of the globals and also improved some comments.
>
> I don't like the discard_lock very much. Perhaps it's OK, but I hope
> that there are better alternatives. One p
Hello,
On Wed, May 15, 2019 at 1:45 PM Goel, Dhruv wrote:
>
>
> Proposed Solution:
>
> We remove the third wait state completely from the concurrent index build.
> When we mark the index as ready, we also mark “indcheckxmin” to true which
> essentially enforces Postgres to not use this index for
David Fetter writes:
> I hope the patch is a little easier to digest as now attached.
To be blunt, I find 500K worth of changes in the regression test
outputs to be absolutely unacceptable, especially when said changes
are basically worthless from a diagnostic standpoint. There are
at least two
On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> David Fetter writes:
> > I hope the patch is a little easier to digest as now attached.
>
> To be blunt, I find 500K worth of changes in the regression test
> outputs to be absolutely unacceptable, especially when said changes
> are basi
Hi,
On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
>> David Fetter writes:
>> > I hope the patch is a little easier to digest as now attached.
>>
>> To be blunt, I find 500K worth of changes in the regression test
>> outputs to be
On Mon, May 13, 2019 at 11:36 PM Robert Haas wrote:
>
> While I'm kvetching, I can't help noticing that undoinsert.c contains
> functions both for inserting undo and also for reading it, which seems
> like a loose end that needs to be tied up somehow. I'm mildly
> inclined to think that we should
Andres Freund writes:
> On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>> Indeed. I think we should move our regression tests to TAP and
>> dispense with this.
> -inconceivably much
Yeah, that's not happening.
Just eyeing the patch again, it seems like most of the test-output churn
is fro
On 2019-May-13, David Fetter wrote:
> I tried changing it to EXEC (EXPLAIN EXECUTE is already a thing), but
> got a giant flock of reduce-reduce conflicts along with a few
> shift-reduce conflicts.
After eyeballing the giant patch set you sent[1], I think EXEC is a
horrible keyword to use -- IMO
Andres Freund writes:
> On 2019-05-15 12:01:07 +1200, Thomas Munro wrote:
>> This is listed as an open item to resolve for 12. IIUC the options on
>> the table are:
>>
>> 1. Do nothing, and ship with effective_io_concurrency + 10.
>> 2. Just use effective_io_concurrency without the hardwired b
On 2019-May-05, Tomas Vondra wrote:
> OK, so here is a patch, using elog() for all places except for the
> input function, where we simply report we don't accept those values.
Hmm, does this actually work? I didn't know that elog() supported
errcode()/errmsg()/etc. I thought the macro definitio
Hi,
On 2019-05-15 11:05:31 -0400, Alvaro Herrera wrote:
> After eyeballing the giant patch set you sent[1], I think EXEC is a
> horrible keyword to use -- IMO it should either be the complete word
> EXECUTE, or we should pick some other word. I realize that we do not
> want to have different sets
On Wed, May 15, 2019 at 12:17:29PM -0400, Alvaro Herrera wrote:
On 2019-May-05, Tomas Vondra wrote:
OK, so here is a patch, using elog() for all places except for the
input function, where we simply report we don't accept those values.
Hmm, does this actually work? I didn't know that elog()
Fabien COELHO wrote:
> >> IMHO this new setting should be on by default: few people know about \; so
> >> it would not change anything for most, and I do not see why those who use
> >> it would not be interested by the results of all the queries they asked
> >> for.
> > I agree with your
Hi all, I’m working on an FDW that would benefit greatly from parallel foreign
scan. I have implemented the callbacks described
here:https://www.postgresql.org/docs/devel/fdw-callbacks.html#FDW-CALLBACKS-PARALLEL.
and I see a big improvement in certain plans.
My problem is that I can’t seem to
Hello,
On 2019-May-15, Andres Freund wrote:
> On 2019-05-15 11:05:31 -0400, Alvaro Herrera wrote:
> > After eyeballing the giant patch set you sent[1], I think EXEC is a
> > horrible keyword to use -- IMO it should either be the complete word
> > EXECUTE, or we should pick some other word. I rea
Hi,
On 2019-05-15 12:55:33 -0400, Korry Douglas wrote:
> Hi all, I’m working on an FDW that would benefit greatly from parallel
> foreign scan. I have implemented the callbacks described
> here:https://www.postgresql.org/docs/devel/fdw-callbacks.html#FDW-CALLBACKS-PARALLEL.
> and I see a big i
Thanks for the quick answer Andres. You’re right - it was parallel_tuple_cost
that was getting in my way; my query returns about 6 million rows so I guess
that can add up.
If I change parallel_tuple_scan from 0.1 to 0.0001, I get a parallel foreign
scan.
With 4 workers, that reduces my execu
Hi,
Don't top quote on these list...
On 2019-05-15 13:31:59 -0400, Korry Douglas wrote:
> Thanks for the quick answer Andres. You’re right - it was
> parallel_tuple_cost that was getting in my way; my query returns about 6
> million rows so I guess that can add up.
>
> If I change parallel_t
On 2019-04-24 00:26, David Rowley wrote:
> I didn't do the exact same test, but if I use COPY instead of \copy,
> then for me patched is faster.
OK, confirmed that way, too.
> For the patch, I wonder if you need this line:
>
> + memcpy(values, slot->tts_values, sizeof(*values) * natts);
>
> If
>> But, nworkers_launched is always set to 0 in
>> InitializeDSMForeignScan(), so that won’t work. Any other ideas?
>
> At that state it's simply not yet known how many workers will be
> actually launched (they might not start successfully or such). Why do
> you need to know it there and not la
Alvaro Herrera writes:
> On 2019-May-15, Andres Freund wrote:
>> On 2019-05-15 11:05:31 -0400, Alvaro Herrera wrote:
>>> After eyeballing the giant patch set you sent[1], I think EXEC is a
>>> horrible keyword to use -- IMO it should either be the complete word
>>> EXECUTE, or we should pick some
Hi,
On 2019-05-15 13:53:26 -0400, Tom Lane wrote:
> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> we should probably just drop the whole idea. It seemed like a great
> idea at the time, but it's going to confuse people not just Bison.
I'm not particularly invested in t
Here's a bunch of message fixes in the postgres.po module. Please
comment if anything seems amiss. This is not a final patch, since
regression output has not been adjusted; I only verified that the
backend still compiles cleanly. Some of the changes are going from this
style of message:
You ne
Hi,
On 2019-04-25 15:43:15 -0700, Andres Freund wrote:
> Hm. I think some of those changes would be a bit bigger than I initially
> though. Attached is a more minimal fix that'd route
> RelationGetNumberOfBlocksForFork() through tableam if necessary. I
> think it's definitely the right answer for
catalog/pg_constraint.h defines a typedef ClonedConstraint,
which AFAICS is no longer referenced anywhere. Is there a
reason not to remove it?
(I noticed this while eyeballing a test pgindent run.)
regards, tom lane
Andres Freund writes:
> Which I dutifully rewrote. But I'm actually not sure it's safe at all
> for heap to rely on t_ctid links to be valid. What prevents a ctid link
> to point to a page that's since been truncated away?
Nothing, but when would the issue come up? The updated tuple must be
newe
On 2019-May-15, Andres Freund wrote:
> - blk = ItemPointerGetBlockNumber(tid);
> - if (blk >= RelationGetNumberOfBlocks(relation))
> - elog(ERROR, "block number %u is out of range for relation
> \"%s\"",
> - blk, RelationGetRelationName(relation));
>
> Wh
Hi,
While looking at [1] I was rephrasing this comment + chck in
heap_get_latest_tid():
-* Since this can be called with user-supplied TID, don't trust the
input
-* too much. (RelationGetNumberOfBlocks is an expensive check, so we
-* don't check t_ctid links again this w
On 2019-May-15, Tom Lane wrote:
> catalog/pg_constraint.h defines a typedef ClonedConstraint,
> which AFAICS is no longer referenced anywhere. Is there a
> reason not to remove it?
Oh, I didn't realize it had become completely unused! It was used for
FK creation in partitioned tables, but we re
On Wed, May 15, 2019 at 06:19:38PM +0800, Hubert Zhang wrote:
Hi all,
When we build hash table for a hash join node etc., we split tuples into
different hash buckets. Since tuples could not all be held in memory.
Postgres splits each bucket into batches, only the current batch of bucket
is in me
On Thu, May 16, 2019 at 9:17 AM Tom Lane wrote:
> I wrote:
> > I experimented with fixing this. I was able to get pg_bsd_indent to
> > distinguish multi-line function declarations from definitions, but it
> > turns out that it doesn't help your concern about the lines being too
> > long after re-
Alvaro Herrera writes:
> On 2019-May-15, Tom Lane wrote:
>> catalog/pg_constraint.h defines a typedef ClonedConstraint,
>> which AFAICS is no longer referenced anywhere. Is there a
>> reason not to remove it?
> Oh, I didn't realize it had become completely unused! It was used for
> FK creation
Thomas Munro writes:
> On Thu, May 16, 2019 at 9:17 AM Tom Lane wrote:
>> A small problem with the "rejiggering" is that it now makes the wrong
>> choice for K&R-style function definitions, causing them to be weirdly
>> indented. For our purposes, that's a non-problem so I'm not excited
>> about
Hi,
On 2019-05-15 15:09:34 -0400, Tom Lane wrote:
> (If we're not checking liveness of x_max before following the link,
> we'd have trouble ...)
I don't think we do everywhere - e.g. in heap_get_latest_tid() case that
made me think about this there's only this as an xmax based loop
termination:
On Thu, May 16, 2019 at 3:53 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-15 12:01:07 +1200, Thomas Munro wrote:
> >> This is listed as an open item to resolve for 12. IIUC the options on
> >> the table are:
> >>
> >> 1. Do nothing, and ship with effective_io_concurrency + 10.
> >>
Hi,
On 2019-05-15 15:07:13 -0400, Alvaro Herrera wrote:
> On 2019-May-15, Andres Freund wrote:
>
> > - blk = ItemPointerGetBlockNumber(tid);
> > - if (blk >= RelationGetNumberOfBlocks(relation))
> > - elog(ERROR, "block number %u is out of range for relation
> > \"%s\"",
> > -
Alvaro Herrera writes:
> Here's a bunch of message fixes in the postgres.po module. Please
> comment if anything seems amiss.
These sorts of changes trouble me a bit from a translatability standpoint:
- errmsg("connect = false and enabled = true are mutually
exclusive optio
On 2019-May-15, Tom Lane wrote:
> Alvaro Herrera writes:
> > Here's a bunch of message fixes in the postgres.po module. Please
> > comment if anything seems amiss.
>
> These sorts of changes trouble me a bit from a translatability standpoint:
>
> - errmsg("connect = false a
Hello,
As discussed elsewhere[1][2], our algorithm for deciding when to give
up on repartitioning (AKA increasing the number of batches) tends to
keep going until it has a number of batches that is a function of the
number of distinct well distributed keys. I wanted to move this minor
issue away
On Tue, May 14, 2019 at 12:19 PM Andres Freund wrote:
> Hi,
>
> On 2019-05-10 14:40:38 -0700, Andres Freund wrote:
> > On 2019-05-01 11:41:48 -0700, Andres Freund wrote:
> > > I'm imagining something like
> > >
> > > if (pg_try_advisory_xact_lock(1))
> > > pg_advisory_xact_lock(2);
> > > else
Hi,
On 2019-05-15 18:34:15 -0700, Melanie Plageman wrote:
> So, I recognize this has already been merged. However, after reviewing the
> test,
> I believe there is a typo in the second permutation.
>
> # Test that speculative locks are correctly acquired and released, s2
> # inserts, s1 updates.
On Thu, May 16, 2019 at 5:46 AM Korry Douglas wrote:
> >> But, nworkers_launched is always set to 0 in
> >> InitializeDSMForeignScan(), so that won’t work. Any other ideas?
> >
> > At that state it's simply not yet known how many workers will be
> > actually launched (they might not start success
On Wed, May 15, 2019 at 6:50 PM Andres Freund wrote:
> > Also, it would make the test easier to understand for me if, for
> instances
> > of the
> > word "lock" in the test description and comments, you specified locktype
> --
> > e.g.
> > advisory lock.
> > I got confused between the speculative
Hi,
On 2019-05-15 20:35:49 -0700, Melanie Plageman wrote:
> > > I noticed that there is not a test case which would cover the speculative
> > > wait
> > > codepath. This seems much more challenging, however, it does seem like a
> > > worthwhile test to have.
> >
> > Shouldn't be that hard to creat
On Wed, May 15, 2019 at 8:36 PM Melanie Plageman
wrote:
>
> On Wed, May 15, 2019 at 6:50 PM Andres Freund wrote:
>
>>
>> > I noticed that there is not a test case which would cover the
>> speculative
>> > wait
>> > codepath. This seems much more challenging, however, it does seem like a
>> > wor
On Wed, May 15, 2019 at 11:54 AM Andres Freund wrote:
> Hi,
>
> On 2019-04-25 15:43:15 -0700, Andres Freund wrote:
>
> > > 3) nodeTidscan, skipping over too large tids
> > >I think this should just be moved into the AMs, there's no need to
> > >have this in nodeTidscan.c
> >
> > I think h
On Wed, May 15, 2019 at 10:46:39AM -0400, Tom Lane wrote:
> Andres Freund writes:
>> On May 15, 2019 7:20:34 AM PDT, David Fetter wrote:
>>> Indeed. I think we should move our regression tests to TAP and
>>> dispense with this.
>
>> -inconceivably much
>
> Yeah, that's not happening.
+1 to the
49 matches
Mail list logo
