On Thu, Sep 26, 2013 at 4:57 AM, Peter Eisentraut wrote:
> On 9/25/13 4:46 AM, David Rowley wrote:
> > Please find attached the new patch ... version v0.5 and also updated
> > benchmark results.
>
> Please fix compiler warnings:
>
> elog.c: In function ‘log_line_prefi
On Fri, Sep 27, 2013 at 4:44 AM, Robert Haas wrote:
> On Wed, Sep 25, 2013 at 4:46 AM, David Rowley
> wrote:
> > Ok, I think I've managed to narrow the performance gap to just about
> nothing
> > but noise, though to do this the code is now a bit bigger. I've add
On Fri, Sep 27, 2013 at 10:28 AM, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 5:18 PM, Robert Haas
> wrote:
> > On Thu, Sep 26, 2013 at 3:55 PM, David Rowley
> wrote:
> >> I think I must have forgot to save it before I emailed it...
> >>
> >> Here&#x
appendStringInfo() vs appendStringInfoString().
So let this be the thread to gather opinions on if my 100kb patch which
replaces appendStringInfo with appendStringInfoString where possible would
be welcomed by the community. Also would using
appendStringInfoStringConst() be going 1 step too far?
Regards
David Rowley
On Sat, Sep 28, 2013 at 9:44 PM, David Rowley wrote:
> I did some benchmarking earlier in the week for the new patch which was
> just commited to allow formatting in the log_line_prefix string. In version
> 0.4 of the patch there was some performance regression as I was doing
> appe
On Sat, Sep 28, 2013 at 11:11 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 28.09.2013 12:44, David Rowley wrote:
>
>> The macro for test 4 was as follows:
>> #define appendStringInfoStringConst(**buf, s) appendBinaryStringInfo(buf,
>> (s), sizeof(
On Sat, Sep 28, 2013 at 11:11 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 28.09.2013 12:44, David Rowley wrote:
>
>> The macro for test 4 was as follows:
>> #define appendStringInfoStringConst(**buf, s) appendBinaryStringInfo(buf,
>> (s), sizeof(
On Sat, Sep 28, 2013 at 9:44 PM, David Rowley wrote:
> I did some benchmarking earlier in the week for the new patch which was
> just commited to allow formatting in the log_line_prefix string. In version
> 0.4 of the patch there was some performance regression as I was doing
> appe
In HEAD of 9.4 I'm getting the following:
D:\9.4\bin>postgres.exe -D d:\9.4\data
LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
PANIC: space reserved for WAL record does not match what was writ
On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund wrote:
> On 2013-10-05 01:05:37 +1300, David Rowley wrote:
> > In HEAD of 9.4 I'm getting the following:
> >
> > D:\9.4\bin>postgres.exe -D d:\9.4\data
> > LOG: database system was shut down at 2013-10-05 00:43:3
On Sat, Oct 5, 2013 at 1:34 AM, David Rowley wrote:
> On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund wrote:
>
>> On 2013-10-05 01:05:37 +1300, David Rowley wrote:
>> > In HEAD of 9.4 I'm getting the following:
>> >
>> > D:\9.4\bin>postgres.exe -D
40 ms
The database contained a single 1 million record table with 6 columns.
Regards
David Rowley
pg_dump_colinsert_v0.1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Oct 5, 2013 at 6:39 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Fri, Oct 4, 2013 at 11:28 AM, Tom Lane wrote:
> > > David Rowley writes:
> > >> Here's a small patch which greatly increases the speed of
> > >
On Wed, Oct 9, 2013 at 5:26 AM, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund
> wrote:
> > On 2013-10-07 13:25:17 -0400, Robert Haas wrote:
> >> On Fri, Oct 4, 2013 at 8:19 AM, Andres Freund
> wrote:
> >> > Could it be that MAXALIGN/TYPEALIGN doesn't really work for values
pg_archivecleanup.exe : fatal error LNK1120:
1 unresolved externals [D:\Postgres\c\pg_archivecleanup.vcxproj]
Regards
David Rowley
--
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via
On Mon, Oct 14, 2013 at 9:45 PM, David Rowley wrote:
> On Sat, Oct 12, 2013 at 2:58 AM, Alvaro Herrera
> wrote:
>
>> Peter Eisentraut escribió:
>> > On Tue, 2013-09-17 at 15:13 +0500, Asif Naeem wrote:
>> > > I did put some time review the patch, ple
On Tue, Oct 15, 2013 at 9:48 AM, Peter Eisentraut wrote:
> On Mon, 2013-10-14 at 23:08 +1300, David Rowley wrote:
>
> >
> > Looks like something like:
> >
> >
> > #ifndef WIN32
> > #define HAVE_VA_COPY 1
> > #endif
> >
> >
> > wo
On Tue, Oct 15, 2013 at 8:00 PM, Asif Naeem wrote:
>
>
>
> On Tue, Oct 15, 2013 at 10:55 AM, David Rowley wrote:
>
>> Though this is not yet enough to get the windows build work with me...
>> I'm still getting link failures for isolationtester.c
>>
>>
just 64bit ones. For me it made
perfect sense, so I'm a bit confused at most of this fuss. Though I do
understand that it's a bit weird that both macros are almost the same on a
64 bit machine...
As for signed vs unsigned, I've not looked at all of the places where
MAXALIGN is used,
ast night and didn't get very far...
I can confirm that you are right just by changing the 128 into 12800 and
compiling, vcregress check worked after that.
Regards
David Rowley
>
> I have a lot of other gripes about this whole patch, but they can
> wait till tomorrow.
>
>
On Wed, Oct 23, 2013 at 4:00 AM, Tom Lane wrote:
> Yeah. As a separate matter, it might be useful to revise stringinfo.c
> and the asprintf code so that *if* the returned value is larger than the
> given buffer size, we use it as a guide to resizing, avoiding the possible
> need to loop multiple
Hi,
I'm just looking at the changed code in commit
3147acd63e0135aff9a6c4b01d861251925d97d9 and I'm wondering if we should
perhaps test the performance of this before assuming too much that it is an
improvement. I'm a bit concerned that now if there is not enough space in
the buffer that we only n
On Sun, Oct 27, 2013 at 3:04 AM, Tom Lane wrote:
> David Rowley writes:
> > I'm just looking at the changed code in commit
> > 3147acd63e0135aff9a6c4b01d861251925d97d9 and I'm wondering if we should
> > perhaps test the performance of this before as
On Mon, Sep 30, 2013 at 10:10 PM, David Rowley wrote:
> On Sat, Sep 28, 2013 at 9:44 PM, David Rowley wrote:
>
>> I did some benchmarking earlier in the week for the new patch which was
>> just commited to allow formatting in the log_line_prefix string. In version
>> 0.
t end applications and allocates memory differently... Is this
the only reason or is there some other special reason for this function
that I can't think of?
If someone wants to give me some guidance on how or if all this should
re-factored, I'll happily supply a patch.
Regards
David Rowley
On Sat, Nov 2, 2013 at 2:27 PM, Tom Lane wrote:
> David Rowley writes:
> > Tom commited some changes to appendStringInfoVA a few weeks ago which
> > allows it to return the required buffer size if the current buffer is not
> > big enough.
>
> > On looking at appen
and in psql the catalog could be queried to see which order these
columns should be displayed in.
For reference I've attached the script I used for testing this.
I'd like to implement this as a project, but before I start any work on it
I'd just like to find out other people's tho
On Mon, Nov 4, 2013 at 3:14 AM, Alvaro Herrera wrote:
> David Rowley escribió:
> > I've just been looking at how alignment of columns in tuples can make the
> > tuple larger than needed.
>
> This has been discussed at length previously, and there was a design
> p
Attached is a small patch which fixes the unused variable warning in the
visual studios build. Seems like VS does not
support __attribute__((unused)) but looks like all other places we must
assign to the variable.
Regards
David Rowley
unused_variable.patch
Description: Binary data
--
Sent
t;
src\interfaces\ecpg\test\pg_regress_ecpg.c(170): warning C4113: 'void
(__cdecl *)(void)' differs in parameter lists from 'init_function'
[D:\Postgres\b\pg_regress_ecpg.vcxproj]
1 Warning(s)
The attached fixes it.
Regards
David Rowley
windows_compiler_warning.patch
Description: Bin
On Sat, Nov 9, 2013 at 7:29 PM, Amit Kapila wrote:
> On Thu, Nov 7, 2013 at 11:43 AM, David Rowley
> wrote:
> > Attached is a small patch which fixes the unused variable warning in the
> > visual studios build. Seems like VS does not support
> > __attribute__((unused))
On 12 September 2015 at 04:24, Andres Freund wrote:
> On 2015-09-12 04:00:26 +1200, David Rowley wrote:
> > I've not done anything yet to remove the #ifdef HAVE_INT64_TIMESTAMP from
> > AppendSeconds(). The only way I can think to handle this is to just
> > make fsec_
On 15 September 2015 at 05:52, Alvaro Herrera
wrote:
> Jim Nasby wrote:
> > On 9/13/15 2:43 AM, David Rowley wrote:
> > >Are you worried about this because I've not focused on optimising float
> > >timestamps as much as int64 timestamps? Are there many
que index (f1, f2, f3, f4), because uniqueness on (f1, f2, f3) gives
> warranty of uniqueness on (f1, f2, f3, f4)
>
>
I'd vote for this too. However, INCLUDE does not seem to be a reserved word
at the moment.
I think this syntax fits in nicely to with non-unique indexes too.
Regards
David
ot even compile. Perhaps including
"tot" or "total" in there might help indicate it's new meaning.
Regards
David Rowley
--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services
aving to edit
each of the existing for() loop that go over the index attributes. This
would just store the idxnattrs + number of included columns. Perhaps
something named idxtotnatts or idxtotalnatts.
Regards
David Rowley
--
David Rowley http://www.2ndQuadrant.com/
<http:
On 15 September 2015 at 23:51, Nicolas Barbier
wrote:
> 2015-09-15 David Rowley :
>
> > I'm also a bit confused where f3 comes in here. If it's UNIQUE on (f1,f2)
> > and we include f4. Where's f3?
>
> Columns f1, f2, f3 are in the internal nodes of the
t is it that I'm missing?
>
>
Joining relations may have more than one matching tuple for any given
unique tuple, therefore the tuples may no longer be unique on the columns
which are in the unique index.
https://commitfest.postgresql.org/6/129/ takes steps to add infrastructure
to
On 23 September 2015 at 10:16, Jim Nasby wrote:
>
>
Attached patch fixes, though I'm not sure if %lld is portable or not.
>
>
I think you could probably use INT64_FORMAT, and cast the stat.st_size to
int64 too.
There's an example in FileRead() in fd.c
Regards
David Ro
could code it to be smart
enough to see through that.
One thing I've not thought of yet is the jointype, and also NULL values
references by the foreign key. Perhaps NULLs don't matter as they won't be
matched by the join condition anyway.
There's a few other things, but it makes se
On 23 September 2015 at 17:11, David Rowley
wrote:
> find_foreign_key_clauses() should look for the longest match and return a
> Bitmap set of the list indexes to the caller.
> It might be possible to fool the longest match logic by duplicating
> clauses, e.g. a1 = b1 AND a1 = b1 and
decimal may take more, or less space, may be slower if cast is
> frequently performed.
>
Are you able to share the processor vendor, and perhaps some other specs of
the machine you obtained these results from?
Regards
David Rowley
--
David Rowley http://www.2ndQuadran
c.id2%2 = a.c_id2%2;
I'm not saying that my version of the patch does any better... I've
actually not tested, but I think we could only use the FK to test this if
we happened to back that up with something like UNIQUE join detection. My
unique join patch aims to add so
On 26 September 2015 at 01:57, Tomas Vondra
wrote:
> Hi,
>
> On 09/25/2015 03:39 AM, David Rowley wrote:
>
>> I looked at this again, and I'm not all that sure it's possible to
>>
> assume that 1.0 / is valid when there's more than one
>> rel
On 28 September 2015 at 20:36, Amit Langote
wrote:
>
> Did you perhaps attach a version of the patch you didn't intend to?
>
Oops. It seems so.
Please find the correct version attached.
Thanks for checking and letting me know.
--
David Rowley http://www.2
On 28 September 2015 at 23:17, Amit Langote
wrote:
> On 2015/09/28 17:04, David Rowley wrote:
> > On 28 September 2015 at 20:36, Amit Langote <
> langote_amit...@lab.ntt.co.jp>
> > wrote:
> >
> >>
> >> Did you perhaps attach a version of the p
ROM generate_series(91,100) s(i);
The join will find exactly 0 tuples between the join of (f, d1) -> d2.
Is my logic here wrong somehow?
--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services
On 29 September 2015 at 01:59, Tomas Vondra
wrote:
> Hi,
>
> On 09/27/2015 02:00 PM, David Rowley wrote:
>
>> I've been working on this again. I've put back the code that you wrote
>> for the looping over each combination of relations from either side of
>&
ng along the lines of : for aggregates such as
AVG(). I believe you'll need something very similar to this to pass the
partial states between worker and master process.
Regards
David Rowley
--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services
;ll need to sort again after the Gather node.
[1]
http://www.postgresql.org/message-id/CAKJS1f9kw95K2pnCKAoPmNw==7fgjsjc-82cy1rb+-x-jz0...@mail.gmail.com
--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services
ime: 0.204 ms
Execution time: 11.575 ms
(8 rows)
Now it could well be that the merge join costs need a bit more work to
avoid a merge join in this case, but as it stands as of today, this is your
performance gain.
Regards
David Rowley
[1]
http://www.postgresql.org/message-id/caczyd
On 13 October 2015 at 20:57, Haribabu Kommi
wrote:
> On Tue, Oct 13, 2015 at 5:53 PM, David Rowley
> wrote:
> > On 13 October 2015 at 17:09, Haribabu Kommi
> > wrote:
> >>
> >> On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas
> >> wrote:
> >
this worth fixing?
--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services
tlist_matches_tupdesc_fastpath.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 5 November 2015 at 13:20, Peter Geoghegan wrote:
> On Fri, Sep 11, 2015 at 9:00 AM, David Rowley
> wrote:
> > Attached is also timestamp_delta.patch which changes pg_ltostr() to use
> the
> > INT_MIN special case that pg_ltoa also uses. I didn't make
patches around their area of expertise rather than putting
their name against the whole thing, likely a commiter would have a better
idea if such a thing was worth the extra overhead.
Regards
David Rowley
e if
SpecialJoinInfo->semi_rhs_exprs and SpecialJoinInfo->semi_operators would
still be needed at all. These were only added in b557226. Changing this
would help reduce the extra planning time when the query contains
semi-joins. To be quite honest, this type of analysis belongs in
anal
On 14 March 2015 at 14:51, David Rowley wrote:
> On 13 March 2015 at 20:34, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
>>
>>
> For all that, I agree that the opition that this kind of separate
>> multiple-nested loops on relations, joi
On 14 March 2015 at 14:51, David Rowley wrote:
> On 13 March 2015 at 20:34, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
>> Unfortunately I can't decide this to be 'ready for commiter' for
>>
> now. I think we should have this
ate table j2(value int not null);
explain select * from j1 inner join (select distinct value from j2) j2 on
j1.id=j2.value;
The left join removal code properly detects this, so I think unique joins
should too.
I can continue working on your patch if you like? Or are you planning to go
further with it?
Regards
David Rowley
igit
exponent.
Going by this:
https://msdn.microsoft.com/en-us/library/0fatw238(v=vs.80).aspx it seems
that it can quite easily be set back to 2.
I've attached a patch which seems to fix the issue.
Regards
David Rowley
diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index
On 22 March 2015 at 18:17, Michael Paquier
wrote:
> On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> Pushed with that additional change. Let's see if the buildfarm thinks.
> >
> > jacana, apparently alone among buildfarm members, does not like it.
>
> All the win
On 20 March 2015 at 21:11, David Rowley wrote:
>
> I can continue working on your patch if you like? Or are you planning to
> go further with it?
>
>
I've been working on this more over the weekend and I've re-factored things
to allow LEFT JOINs to be properly marked
27;t include code to support the space padding for
the new log_line_prefixes?
The others support % in the prefix, to allow left or right
alignment of the item.
Also, what's the reason for timestamp_str? Could you not just use
appendStringInfo() and skip the temporary buffer?
Regards
David Rowley
ot cygwin) critter that does the 128bit dance...
>
Yeah, I can't recreate the issue locally on my windows machine, but I may
try with gcc if I can get some time.
Regards
David Rowley
#x27;d need to lookup the system catalogs for just about
every SQL statement... This would be very slow indeed!
Regards
David Rowley
pass.
> At Sun, 22 Mar 2015 19:42:21 +1300, David Rowley
> wrote in <
> caaphdvrkwmmtwkxfn4uazyza9jql1c7uwbjbtuwfr69rqlv...@mail.gmail.com>
> > On 20 March 2015 at 21:11, David Rowley wrote:
> > >
> > > I can continue working on your patch if you like? Or ar
s.
It seems unlikely that any of those things will happen for 9.5.
Does anybody object to me moving this to June's commitfest?
Regards
David Rowley
ion plan for the particular query."
I'm finding it a bit hard to get a true meaning from that, but if I'm not
mistaken it means that the serial plan will be preferred over a parallel
plan, as if the parallel plan does not get allocated any workers at
execution time, then we don't want to be left with a slow plan...
Apologies if any of this has been discussed any already designed around, I
just didn't see anything in the emails to indicate that it has.
Regards
David Rowley
utor time.
Cons:
* May produce non optimal plans if no worker processes are available during
execution time.
* Planning overhead for considering parallel paths.
* The parallel plan may blow out buffer caches due to increased I/O of
parallel plan.
Of course please say if I've missed any pro or con.
Regards
David Rowley
On 8 April 2015 at 15:46, Amit Kapila wrote:
> On Wed, Apr 8, 2015 at 1:53 AM, Kevin Grittner wrote:
> >
> > David Rowley wrote:
> >
> > > If we attempt to do this parallel stuff at plan time, and we
> > > happen to plan at some quiet period, or perhaps w
On 9 April 2015 at 00:12, Amit Kapila wrote:
> On Wed, Apr 8, 2015 at 3:30 PM, David Rowley wrote:
> >
> > On 8 April 2015 at 15:46, Amit Kapila wrote:
> >>
> >> I think there is always a chance that resources (like parallel-workers)
> >> won't b
I've attached a small patch which just fixes a few appendStringInfo* calls
that are not quite doing things the way that it was intended.
Regards
David Rowley
appendstringinfo_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Attached is a small patch which removes some duplicated words that have
crept into some comments.
Regards
David Rowley
duplicate_words_in_comments_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 21 April 2015 at 06:26, Robert Haas wrote:
> On Wed, Apr 8, 2015 at 3:34 AM, David Rowley wrote:
> > In summary it sounds like with my idea we get:
> >
> > Pros
> > * Optimal plan if no workers are available at execution time.
> > * Parallelism possible if t
ion of t2 rows, and this does not matter as we're
performing an anti join anyway (same applies for semi join).
Regards
David Rowley
anti_join_with_pulledup_outer_joins_fix_attempt.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eId macro uses UINT16_MAX and is also used in xact.c.
Regards
David Rowley
UINT16_MAX_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5 May 2015 at 06:23, Robert Haas wrote:
>
> OK, committed and back-patched.
>
There's a couple of problems with this that the windows buildfarm members
are not happy with.
The attached patch seems to work locally.
Regards
David Rowley
fsync_win32_fix.patch
Descriptio
On 12 May 2015 at 12:57, Peter Eisentraut wrote:
> On 4/11/15 6:25 AM, David Rowley wrote:
> > I've attached a small patch which just fixes a few appendStringInfo*
> > calls that are not quite doing things the way that it was intended.
>
> done
>
>
Thank you fo
nd pass that
trimmed list down to clauselist_selectivity() for selectivity estimates. Or
perhaps a better way would be just to teach clauselist_selectivity() about
foreign keys. Likely clauselist_selectivity() would just have to skip over
RestrictInfo items that are part of a foreign key.
Regards
David Rowley
To get things going, I'm picking up the Commitfest
> Manager Mace I found from behind the dumpster now.
>
>
Thanks Heikki,
I was wondering if you knew what the plan is for the remaining ready for
committer patches from the June commitfest?
Regards
David Rowley
rnals
[c:\prog\bf\root\HEAD\pgsql.build\pg_upgrade_support.vcxproj]
0 Warning(s)
2 Error(s)
Regards
David Rowley
IsBinaryUpgrade_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 5, 2014 at 10:35 PM, David Rowley wrote:
>
> Currently most of my changes are in analyzejoin.c, but I did also have to
> make changes to load the foreign key constraints so that they were
> available to the planner. One thing that is currently lacking, which would
> l
On Wed, Aug 27, 2014 at 1:40 AM, Heikki Linnakangas wrote:
> On 08/26/2014 03:28 PM, David Rowley wrote:
>
>> Any ideas or feedback on this would be welcome
>>
>
> Before someone spends time reviewing this patch, are you sure this is
> worth the effort? It seems like
The attached small patch fixes the following warning:
src\backend\utils\adt\arrayfuncs.c(5613): warning C4013: '_isnan'
undefined; assuming extern returning int [D:\Postgres\a\postgres.vcxproj]
The fix is pretty much just a copy and paste from costsize.c
Regards
Da
hat has its varno in the targetlist of the
query. Though perhaps a few benchmarks will determine if this is worth it
or not.
Comments are welcome. -- I'm really hoping this patch generates a bit more
interest than the SEMI/ANTI join removal one!
Regards
David Rowley
inner_join_rem
On Fri, Sep 12, 2014 at 3:35 AM, Robert Haas wrote:
> On Thu, Sep 11, 2014 at 7:14 AM, David Rowley
> wrote:
> >
>
> 1. I don't think that I'm currently handling removing eclass members
> > properly. So far the code just removes the Vars that belong to the
>
On Fri, Sep 12, 2014 at 3:47 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Sep 11, 2014 at 7:14 AM, David Rowley
> wrote:
> >> 5. I've added a flag to pg_class called relhasfkey. Currently this gets
> set
> >> to true when a foreign key is adde
On Sat, Sep 13, 2014 at 1:38 AM, Tom Lane wrote:
> David Rowley writes:
> > On Fri, Sep 12, 2014 at 3:35 AM, Robert Haas
> wrote:
> >> I haven't read the patch, but I think the question is why this needs
> >> to be different than what we do for left join re
in c
on b.c_id = c.id;
QUERY PLAN
-
Seq Scan on a (cost=0.00..31.40 rows=2140 width=8)
Planning time: 1.061 ms
Regards
David Rowley
inner_join_removals_2014-09-17_d17e608.patch
Description: Binary data
--
Sent via pgsql-hacke
at's
promising enough to make it worth the extra planning cycles of setting this
uniquejoin flag.
Does anyone have any thoughts on this?
Regards
David Rowley
way might not be too bad as I think the outer window will have no need
to perform another sort, since the inner window clause has sorted it the
right way already. Though something like change_number() would make this a
bit more pretty. It's almost like rank(), but with a parameter.
Regards
David Rowley
On Fri, Sep 26, 2014 at 12:36 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 09/16/2014 01:20 PM, David Rowley wrote:
>
>> + /*
>> +* We mustn't allow any joins to be removed if there are any
>> pending
>> +* fore
On Mon, Sep 29, 2014 at 2:41 AM, Andres Freund
wrote:
> On 2014-09-28 17:32:21 +1300, David Rowley wrote:
> > My understanding of foreign keys is that any pending foreign key triggers
> > will be executed just before the query completes, so we should only ever
> > encounte
On Tue, Sep 30, 2014 at 12:42 AM, Andres Freund
wrote:
> On 2014-09-29 22:42:57 +1300, David Rowley wrote:
>
> > I've made a change to the patch locally to ignore foreign
> > keys that are marked as deferrable.
>
> I have serious doubts about the general usefulness i
On Wed, Oct 1, 2014 at 12:01 AM, Andres Freund
wrote:
> On 2014-09-30 23:25:45 +1300, David Rowley wrote:
> >
> > I've not quite gotten my head around how we might stop the unneeded
> > relation from being the primary path to join the other inner relations,
> >
On Wed, Oct 1, 2014 at 1:34 AM, Andres Freund
wrote:
> On 2014-10-01 01:03:35 +1300, David Rowley wrote:
> > On Wed, Oct 1, 2014 at 12:01 AM, Andres Freund
> > wrote:
> >
> > > On 2014-09-30 23:25:45 +1300, David Rowley wrote:
> > > >
> > >
On Tue, Oct 7, 2014 at 3:46 AM, Robert Haas wrote:
> On Mon, Oct 6, 2014 at 5:57 AM, David Rowley wrote:
> > Can anyone shed any light on how I might determine where the scan rel is
> in
> > the tree? I need to find it so I can check if the RangeTblEntry is
> marked as
uted)
-> Seq Scan on b (never executed)
-> Hash (never executed)
-> Seq Scan on c (never executed)
Execution time: 0.092 ms
(10 rows)
>From this I can see easily that the joins to b and c were skipped, however
the output the way it is at the moment is quite useless for regression
testing with.
Regards
David Rowley
ests.
Can you think of some other way that I could test this? Keep in mind
there's no trace of the removal in the EXPLAIN without ANALYZE.
Regards
David Rowley
On Thu, Oct 9, 2014 at 12:40 AM, Andres Freund
wrote:
> On 2014-10-09 00:21:44 +1300, David Rowley wrote:
> > Ok, so I've been hacking away at this for a couple of evenings and I
> think
> > I have a working prototype finally!
>
> Cool!
>
>
Patch attached.
401 - 500 of 915 matches
Mail list logo
