Hi, Thomas!
> 14 окт. 2018 г., в 9:18, Thomas Munro
> написал(а):
>
> + /* Prefetch the bucket for the next key */
> + uint32 next_hash = hash_uint32(DatumGetInt32(keyval) + 1);
> + uint32 next_bucket = next_hash % hashtable->nbuckets;
> +
Hello!
> 31 авг. 2018 г., в 2:40, Thomas Munro
> написал(а):
> A related topic is the cache-unfriendliness of traditional binary
> searches of sorted data. Check out "Array Layouts for
> Comparison-Based Searching"[1] if you haven't already. It says that
> if your array fits in L2 cache, as ou
> On Sun, 14 Oct 2018 at 06:19, Thomas Munro
> wrote:
>
> Cache-oblivious hash joins cause a lot of TLB and cache misses.
> ...
> (There is another class of cache-aware hash join algorithms that partition
> carefully up front to avoid them; that's not us.)
Just out of curiosity, can you please e
On Mon, Oct 15, 2018 at 12:16 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Sun, 14 Oct 2018 at 06:19, Thomas Munro
> > wrote:
> > Cache-oblivious hash joins cause a lot of TLB and cache misses.
> > ...
> > (There is another class of cache-aware hash join algorithms that partition
> > ca
On 10/13/2018 09:59 PM, Michael Paquier wrote:
On Sat, Oct 13, 2018 at 05:53:00PM -0400, Andrew Dunstan wrote:
It occurred to me that a pretty simple fix could just be to blacklist
everything that didn't start with a digit. The whitelist approach is
probably preferable... depends how urgent w
I was crosseyed yesterday due to merge conflicts, but this still seems odd.
I thought that final row counts would not vary with the details of the chosen
plan. Which seems to hold true when I disable parallel join or hash join, but
not for PWJ.
I noticed this behavior while joining our own table
Andres Freund writes:
> On 2018-10-12 19:47:40 -0400, Tom Lane wrote:
>> So I went looking for a different example to plug in there, and soon
>> found that there weren't any. If you change all the physically_coercible
>> calls in that script to binary_coercible, its output doesn't change.
>> I'm
Justin Pryzby writes:
> I was crosseyed yesterday due to merge conflicts, but this still seems odd.
> I thought that final row counts would not vary with the details of the chosen
> plan. Which seems to hold true when I disable parallel join or hash join, but
> not for PWJ.
There are good reason
> On 10/13/18, Amit Kapila wrote:
>> I think you have found a good way to avoid creating FSM, but can't we
>> use some simpler technique like if the FSM fork for a relation doesn't
>> exist, then check the heapblk number for which we try to update the
>> FSM and if it is lesser than HEAP_FSM_EXTEN
On Tue, Oct 2, 2018 at 3:40 AM Michael Paquier wrote:
>
> The last patch set does not apply, so this is moved to next CF, waiting
> on author as new status.
>
Updated the last patch so it can apply cleanly on HEAD.
About the bugfixes, do you think it is better to move to another thread?
Best r
On Mon, Oct 15, 2018 at 12:03 AM Andrey Borodin wrote:
> 31 авг. 2018 г., в 2:40, Thomas Munro
> написал(а):
> A related topic is the cache-unfriendliness of traditional binary
> searches of sorted data. Check out "Array Layouts for
> Comparison-Based Searching"[1] if you haven't already. It s
Robert Haas writes:
> On Thu, Mar 15, 2018 at 11:27 AM, Tom Lane wrote:
>> We've long made fun of Oracle(TM) for the fact that if you just want
>> to evaluate some expressions, you have to write "select ... from dual"
>> rather than just "select ...". But I've realized recently that there's
>> a
Hi,
On 2018-09-29 20:48:10 -0700, Andres Freund wrote:
> In my opinion the current WITH OIDs system has numerous weaknesses:
>
> 1) The fact that oids are so magic means that if we get pluggable
>storage, the design of the potential pluggable systems is constrained
>and similar magic has
On Fri, Mar 16, 2018 at 4:27 AM Tom Lane wrote:
> We've long made fun of Oracle(TM) for the fact that if you just want
> to evaluate some expressions, you have to write "select ... from dual"
> rather than just "select ...". But I've realized recently that there's
> a bit of method in that madnes
Andres Freund writes:
> Does anybody have engineering / architecture level comments about this
> proposal?
FWIW, I'm -1 on making OIDs be not-magic for SELECT purposes. Yeah, it's
a wart we wouldn't have if we designed the system today, but the wart is
thirty years old. I think changing that wi
On Sun, Oct 14, 2018 at 10:24:55AM -0400, Andrew Dunstan wrote:
> [snip]
Thanks a lot for the review, Andrew!
> This code now seems redundant:
>
> if (strcmp(fn, ".") == 0 ||
> strcmp(fn, "..") == 0)
> return true;
Indeed. I have renamed skipfile() to isRelFi
Hi,
On 2018-10-14 18:34:50 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Does anybody have engineering / architecture level comments about this
> > proposal?
>
> FWIW, I'm -1 on making OIDs be not-magic for SELECT purposes. Yeah, it's
> a wart we wouldn't have if we designed the system tod
On Mon, Oct 15, 2018 at 11:35 AM Tom Lane wrote:
> Andres Freund writes:
> > Does anybody have engineering / architecture level comments about this
> > proposal?
>
> FWIW, I'm -1 on making OIDs be not-magic for SELECT purposes. Yeah, it's
> a wart we wouldn't have if we designed the system today
On 10/14/2018 06:41 PM, Michael Paquier wrote:
On Sun, Oct 14, 2018 at 10:24:55AM -0400, Andrew Dunstan wrote:
[snip]
Thanks a lot for the review, Andrew!
This code now seems redundant:
if (strcmp(fn, ".") == 0 ||
strcmp(fn, "..") == 0)
return true;
Hi,
I reviewed pgbench-prp-func-6.patch.
(1) modular_multiply()
In modular_multiply(), the numbers of digits of inputs are checked in
order to determine using the interleaved modular multiplication
algorithm or not. However, the check condition absolutely depends on the
implementation of pseu
I wrote:
> * There's a hack in nodeResult.c to prevent the executor from crashing
> on a whole-row Var for an RTE_RESULT RTE, which is something that the
> planner will create in SELECT FOR UPDATE cases, because it thinks it
> needs to provide a ROW_MARK_COPY image of the RTE's output. We might
>
On Sun, Oct 14, 2018 at 1:09 AM John Naylor wrote:
>
> On 10/13/18, Amit Kapila wrote:
>
> > I think you have found a good way to avoid creating FSM, but can't we
> > use some simpler technique like if the FSM fork for a relation doesn't
> > exist, then check the heapblk number for which we try t
> 15 окт. 2018 г., в 2:38, Thomas Munro
> написал(а):
>
> On Mon, Oct 15, 2018 at 12:03 AM Andrey Borodin wrote:
>> 31 авг. 2018 г., в 2:40, Thomas Munro
>> написал(а):
>> A related topic is the cache-unfriendliness of traditional binary
>> searches of sorted data. Check out "Array Layout
Hi,
On Tue, Oct 2, 2018 at 7:28 PM Jonathan S. Katz
wrote:
> Hi,
>
> Based on the current status of the open items and where we are at in the
> release cycle, the date for the first release candidate of PostgreSQL 11
> will be 2018-10-11.
>
> If all goes well with RC1, the PostgreSQL 11.0 GA rel
On Sat, 13 Oct 2018 at 04:02, Andres Freund wrote:
> > > > @@ -2024,7 +2024,18 @@ FormIndexDatum(IndexInfo *indexInfo,
> > > > Datum iDatum;
> > > > boolisNull;
> > > >
> > > > - if (keycol != 0)
> > > > + if (keycol < 0)
>
25 matches
Mail list logo
