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)
>
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
> 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
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
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
>
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
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;
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
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 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
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 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
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
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
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
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 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
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
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
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
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
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 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
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
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;
> +
25 matches
Mail list logo
