Hi Hackers,
The planner will use big table as inner table in hash join if small table
have fewer unique values.
But this plan is much slower than using small table as inner table. This
problem occurs on master
branch without parallel scan.
For example
create table t_small(a int);
create table
On Fri, Nov 15, 2019 at 6:24 PM Alexey Kondratov
wrote:
> On 11.11.2019 16:00, Surafel Temesgen wrote:
> >
> >
> > Next, you use DestRemoteSimple for returning conflicting tuples back:
> >
> > +dest = CreateDestReceiver(DestRemoteSimple);
> > +dest->rStartup(dest,
On Fri, 15 Nov 2019 at 11:54, Amit Kapila wrote:
>
> On Wed, Nov 13, 2019 at 10:02 AM Masahiko Sawada
> wrote:
> >
> > I've done some tests while changing shared buffer size, delays and
> > number of workers. The overall results has the similar tendency as the
> > result shared by Dilip and
po 18. 11. 2019 v 7:37 odesílatel Amit Kapila
napsal:
> On Mon, Nov 18, 2019 at 10:59 AM Pavel Stehule
> wrote:
> > po 18. 11. 2019 v 6:24 odesílatel Amit Kapila
> napsal:
> >>
> >> On Mon, Nov 18, 2019 at 10:33 AM Pavel Stehule
> wrote:
> >> >
> >> > po 18. 11. 2019 v 4:43 odesílatel vignesh
On Mon, 18 Nov 2019 at 15:34, Amit Kapila wrote:
>
> On Mon, Nov 18, 2019 at 11:37 AM Masahiko Sawada
> wrote:
> >
> > On Wed, 13 Nov 2019 at 14:31, Amit Kapila wrote:
> > >
> > >
> > > Based on these needs, we came up with a way to allow users to specify
> > > this information for IndexAm's.
On Mon, Nov 18, 2019 at 10:59 AM Pavel Stehule wrote:
> po 18. 11. 2019 v 6:24 odesílatel Amit Kapila
> napsal:
>>
>> On Mon, Nov 18, 2019 at 10:33 AM Pavel Stehule
>> wrote:
>> >
>> > po 18. 11. 2019 v 4:43 odesílatel vignesh C napsal:
>> >>
>> >>
>> >> I had seen that isolation
On Mon, Nov 18, 2019 at 11:37 AM Masahiko Sawada
wrote:
>
> On Wed, 13 Nov 2019 at 14:31, Amit Kapila wrote:
> >
> >
> > Based on these needs, we came up with a way to allow users to specify
> > this information for IndexAm's. Basically, Indexam will expose a
> > variable amparallelvacuumoptions
On Sun, Nov 17, 2019 at 12:56:52PM +0100, Dmitry Dolgov wrote:
> > On Wed, Jul 31, 2019 at 11:51:17PM -0700, Noah Misch wrote:
> > > Also, if I understand the data-loss hazard properly, it's what you
> > > said in the other thread: the latest_page_number could advance after
> > > we make our
On Wed, 13 Nov 2019 at 14:31, Amit Kapila wrote:
>
> On Wed, Nov 13, 2019 at 9:48 AM Amit Kapila wrote:
> >
> > Yeah, 0,2,3 and 4 sounds reasonable to me. Earlier, Dilip also got
> > confused with option 1.
> >
>
> Let me try to summarize the discussion on this point and see if others
> have
po 18. 11. 2019 v 6:24 odesílatel Amit Kapila
napsal:
> On Mon, Nov 18, 2019 at 10:33 AM Pavel Stehule
> wrote:
> >
> > po 18. 11. 2019 v 4:43 odesílatel vignesh C
> napsal:
> >>
> >>
> >> When we don't specify -e option, the query used to drop db will not be
> >> printed like below:
> >>
On Mon, Nov 18, 2019 at 10:33 AM Pavel Stehule wrote:
>
> po 18. 11. 2019 v 4:43 odesílatel vignesh C napsal:
>>
>>
>> When we don't specify -e option, the query used to drop db will not be
>> printed like below:
>> ./dropdb testdb1
>> When we specify -e option, the query used to drop db will be
po 18. 11. 2019 v 4:43 odesílatel vignesh C napsal:
> On Sat, Nov 16, 2019 at 1:25 PM Pavel Stehule
> wrote:
> >> >
> >> > updated patch attached
> >> >
> >>
> >> Thanks Pavel for providing updated version.
> >> Few comments:
> >> I felt the help text seems incomplete:
> >> @@ -159,6 +167,7
On Tue, Nov 05, 2019 at 02:53:35PM -0800, Noah Misch wrote:
> I started pre-commit editing on 2019-10-28, and comment+README updates have
> been the largest part of that. I'll check my edits against the things you
> list here, and I'll share on-list before committing. I've now marked the CF
>
On Sat, Nov 16, 2019 at 1:25 PM Pavel Stehule wrote:
>> >
>> > updated patch attached
>> >
>>
>> Thanks Pavel for providing updated version.
>> Few comments:
>> I felt the help text seems incomplete:
>> @@ -159,6 +167,7 @@ help(const char *progname)
>> printf(_("\nOptions:\n"));
>>
On Sun, Nov 17, 2019 at 11:23:23PM +, Andrew Gierth wrote:
> > "David" == David Fetter writes:
>
> First, in testing the patch I found there were indeed some missing
> cases: the sortsupport version of the comparator needs to be fixed too.
> I attach a draft addition to your patch, you
On Mon, Nov 18, 2019 at 1:49 PM Alvaro Herrera wrote:
> On 2019-Nov-18, Thomas Munro wrote:
> > Nice idea. Here's one like that, that just does the counting at the
> > end and looks out for readline control codes. It's pretty naive about
> > what "width" means though: you'll get two spaces for
On 2019-Nov-18, Thomas Munro wrote:
> Nice idea. Here's one like that, that just does the counting at the
> end and looks out for readline control codes. It's pretty naive about
> what "width" means though: you'll get two spaces for UTF-8 encoded é,
> and I suppose a complete implementation
> "David" == David Fetter writes:
First, in testing the patch I found there were indeed some missing
cases: the sortsupport version of the comparator needs to be fixed too.
I attach a draft addition to your patch, you should probably look at
adding test cases that need this to work.
David>
On Sun, Nov 17, 2019 at 02:30:35PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Please find attached a patch for $Subject.
>
> I think there's a reason why this hasn't been proposed before.
>
> Back before we had full support of ASC/DESC index sort order, there was
> interest in having
On Fri, Nov 15, 2019 at 3:58 AM Tom Lane wrote:
> Kyotaro Horiguchi writes:
> > This seems assuming %x are a kind of stable (until semicolon)
> > function. But at least %`..` can be volatile. So, I think the %w
> > thing in PROMPT2 should be able to refer the actual prompt string
> > resulted
Alvaro Herrera writes:
> On 2019-Nov-15, Tom Lane wrote:
>> If we add a GUC-check-hook test, then the problem of misconfiguration
>> is reduced to the previously unsolved problem that we have crappy
>> feedback for erroneous on-the-fly configuration changes. So it's
>> still unsolved, but at
> "Tom" == Tom Lane writes:
Tom> Lastly, your proposed use-case has some attraction, but this
Tom> proposal only supports it if the column you need to be differently
Tom> sorted is textual. What if the sort columns are all numerics and
Tom> timestamps?
There are already trivial ways to
David Fetter writes:
> Please find attached a patch for $Subject.
I think there's a reason why this hasn't been proposed before.
Back before we had full support of ASC/DESC index sort order, there was
interest in having reverse-sort operator classes, and there are bits and
pieces still in the
Folks,
Please find attached a patch for $Subject.
Motivation:
When people are doing keyset pagination, the simple cases redound to
adding a WHERE that looks like
(a, b, c) > (most_recent_a, most_recent_b, most_recent_c)
which corresponds to an ORDER BY clause that looks like
ORDER BY
On Mon, Nov 11, 2019 at 2:42 AM Alexander Korotkov
wrote:
> I'm sorry for late reply. I was busy with various things. Also
> digging into these details took some time. Please find my explanation
> below.
>
> On Wed, Oct 30, 2019 at 2:34 AM Peter Geoghegan wrote:
> > In general, it seems very
On Wed, Nov 13, 2019 at 8:45 PM Andres Freund wrote:
> Hi,
>
> On 2019-11-13 12:26:34 -0500, Robert Haas wrote:
> > TL;DR: I'm not sure that we need 0001; I propose to commit 0002; and I
> > have some concerns about 0003 and am interested in working further on
> > it.
>
> Thanks for looking at
> On Wed, Jul 31, 2019 at 11:51:17PM -0700, Noah Misch wrote:
Hi,
> > Also, if I understand the data-loss hazard properly, it's what you
> > said in the other thread: the latest_page_number could advance after
> > we make our decision about what to truncate, and then maybe we could
> > truncate
Hi
út 12. 11. 2019 v 22:51 odesílatel Nikita Glukhov
napsal:
> On 12.11.2019 20:54, Pavel Stehule wrote:
>
> > Hi
> >
> > please, can you rebase 0001-SQL-JSON-functions-v40.patch. I have a
> > problem with patching
> >
> > Pavel
>
> Attached 41th version of the patches rebased onto current
On Sat, Sep 28, 2019 at 4:20 AM Bruce Momjian wrote:
> On Wed, Sep 4, 2019 at 06:18:31PM +1200, Thomas Munro wrote:
> > A few years back[1] I experimented with a simple readiness API that
> > would allow Append to start emitting tuples from whichever Foreign
> > Scan has data available, when
29 matches
Mail list logo
