fore then. There's a
faint chance I can get to it this weekend.
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
L/PerlU.
I don't think we should be tied too closely to a string representation,
although possibly the first and simplest callback function would simply
stringify the quals.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
need to rerun the tests with default_stats_target set to
the old value? I presume he has actually done this already in order to
come to the conclusion he did about the cause of the regression.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
See the attached file for details
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
This analysis makes sense - I think using memcmp is clearly wrong here.
cheers
andrew
Jan Wieck said:
> On a second thought,
>
> I still believe that this is just garbage in the padding bytes after
> the IPV4 address. The code currently bind()'s and connect()'s
>
Hi,
This is Andrew with ProV International.
I have
direct client requirement for the position of PostGre Database Developer
at San Diego, CA. For you reference given below is the
requirement. If you find this interesting and matching to skills then
please send across your updated
Variable values can be defined by -D option.
>
> - \set command now allows arithmetic calculations.
>
Was there a previous patch posted for this? I don't recall seeing it.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
le part. (for example,
> column type change proposal for pgbench tables).
It's not a big deal, but I was under the impression that even in these
circumstances a patch should be posted first, especially if it changes
user visible behaviour.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
1300)
> ...
> #endif
>
> replacing it with
> #ifdef WIN32
> #if (_MSC_VER < 1300)
> ...
> #endif
> #endif
>
> fixed the problem.
>
No doubt, but that's quite a different test.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
a!
>
>
This is not really a good argument. Might it not be possible that there is
a sweeter spot somewhere in the middle? I don't think anyone wants
something very heavy handed.
cheers
andrew
---(end of broadcast)---
he "problem in need of solving," it's what Andrew Dunstan
>> > referred to as "splendid isolation," which is another way of saying,
>> > "letting the thing you've taken on gather dust while people think
>> > you're working on it.&q
rive them away from
> doing anything at all.
The former is much more what I had in mind than the latter. Let's do that.
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
quot;we" --- ie, who's
> going to do the legwork? We surely don't want multiple people pestering
> the same developer ...
>
Perl has its pumpking ... maybe we need a designated "holder of the
trunk". I see that as a Core function.
cheers
andrew
e done things
without discussing them, and were found not to be accepatble. The more
complex features get, the more communication is needed.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ore, but
> we'll wait till we're pretty certain it's feature-stable.
>
My impression from this post
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php was that
moving it into core should be doable for 8.3. I hope I didn't
misunderstand.
cheers
andrew
and typos.
>
In any case, I had some questions:
. is it compatible with PLSQL?
. can the effect be achieved by assigning to a composite?
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
starts at 19 after, so somewhere near half past is
> probably the optimal time. (I'd suggest picking a random time near half
> past, else all the buildfarm members will gang up on the server at once
> ...)
>
is this also true of the cvsup server?
cheers
andrew
-
Jim Nasby wrote:
> Oh, I didn't realize there was a CVSup server. I think it'd be good
> to promote that over CVS, as it's (supposedly) much easier on the
> hosting machine.
>
> Andrew, is there a way to get the buildfarm to use cvsup instead of
> cvs? Does the s
Andrew Hammond wrote:
> I need to write a perl module which will parse a .pgpass file into a
> reasonable data-structure in memory. I may extend it later to go in the
> other direction (given a populated datastructure, write a .pgpass).
>
> The first question that came to mind is
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> domains.c contains the followng snippet in domain_in():
>
>> else* if (my_extra->domain_type != domainType)
>> domain_state_setup(my_extra, domainType, false,
>>
We forgot to mention that we'll need to implement domains over enums and
arrays of enums too.
cheers
andrew
Tom Dunstan wrote:
> Hi guys
>
> Andrew and I got together and worked out a more detailed idea of how we
> want to add enums to the postgresql core. This follows on fr
with the PL in
> question ... and Python's not my language.
>
>
does it have docs?
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
Peter Eisentraut wrote:
> OTRS was recommended to me as a bug tracker. Has anyone used that?
>
Not me, but I see that they use bugzilla for bug tracking ... see
http://bugs.otrs.org/index.cgi
cheers
andrew
---(end of broadcast)---
TIP 3
Hi
I am modifying the source code. I want to look up some information
from some tables while parsing the queries. What functions I can use
to look up tables? btw I am using version 7.3. Thanks.
--
andrew
---(end of broadcast)---
TIP 4: Have you
ty of
> examples in the code of how to access tables, which should be a helpful
> guide.
>
> -Neil
It is not in the raw parser. I meant inside the transformStmt(). What
is "friends"? Could you possibly point out at least one place that
illustrates how to access tables?
Than
nformation of initdb, it only creates other catalogs. What
steps did I miss here?
--
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
oh, my mistake. I only do "make install-bin". Now it is successfully
created. Thanks.
On 2/8/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> andrew wrote:
>
> > I am trying to add a new catalog to the system. I had followed the
> > instructions in the comments. N
On 02/26/2016 10:59 PM, Robert Haas wrote:
On Sat, Feb 27, 2016 at 9:00 AM, Andrew Dunstan wrote:
Sure. Saving three lines of Makefile duplication is hardly a
world-shattering event, so I thought there might be some other
purpose. But I'm not against saving three lines of duplic
On 02/27/2016 09:25 AM, Robert Haas wrote:
On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan wrote:
What I had in mind was something like the attached.
In testing this seems to do the right thing, and the nice part is that it
will be picked up by the buildfarm in the one case that's rel
On 02/27/2016 01:24 PM, John Gorman wrote:
On Sat, Feb 27, 2016 at 9:25 AM, Robert Haas <mailto:robertmh...@gmail.com>> wrote:
On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan
mailto:and...@dunslane.net>> wrote:
> Perhaps what we need to do is modify pg_reg
one in ./configure.
Attached is a patch to address those two issues.
Good work. There seem to be some unrelated whitespace changes. Shouldn't
this just be two extra lines?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
27;m assuming the changes
would be pretty localized, at least in src/tools/msvc, and adding a new
compile shouldn't break anything with existing compilers.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
dc6> The sed script
appears to have been stable for a long time, so I don't think we need to
be too concerned about possibly maintaining two versions.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
On 03/05/2016 01:31 PM, Michael Paquier wrote:
On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan wrote:
Here is a translation into perl of the sed script, courtesy of the s2p
incarnation of psed: <https://gist.github.com/adunstan/d61b1261a4b91496bdc6>
The sed script appears to have been
probably a buildfarm module would be the way to go. We might need to add
a new module hook to support it, to run right after make(), but that
would be a one line addition to run_build.pl.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/08/2016 08:32 AM, Michael Paquier wrote:
On Mon, Mar 7, 2016 at 10:40 PM, Michael Paquier
wrote:
On Sun, Mar 6, 2016 at 5:55 AM, Andrew Dunstan wrote:
On 03/05/2016 01:31 PM, Michael Paquier wrote:
On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan
wrote:
Here is a translation into
On 03/08/2016 10:43 AM, Tom Lane wrote:
Andrew Dunstan writes:
Do we already have a hard dependency on perl for all non-Windows builds?
I know it's been discussed but I don't recall. If so, back to what version?
I think the policy is we require perl for building from a git pull,
b
ripts is pretty minimal.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
aming the values, not the enum itself.
I don't know of any plans, but it would be a useful thing. I agree it
wouldn't be too hard. The workaround is to do an update on pg_enum
directly, but proper SQL support would be much nicer.
cheers
andrew
--
Sent via pgsql-hackers mail
On 03/09/2016 11:07 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/09/2016 09:56 AM, Matthias Kurz wrote:
Right now it is not possible to rename an enum value.
Are there plans to implement this anytime soon?
I don't know of any plans, but it would be a useful thing. I agree it
wou
o we need to do?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
heers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/08/2016 07:40 PM, Michael Paquier wrote:
On Wed, Mar 9, 2016 at 1:07 AM, Andrew Dunstan wrote:
Michael's patch proposes to replace the use of sed to generate probes.h with
the perl equivalent everywhere. That has the advantage that we keep to one
script to generate probes.h, b
On 03/18/2016 09:54 AM, Robert Haas wrote:
On Thu, Mar 17, 2016 at 11:21 AM, Andrew Dunstan wrote:
On 03/17/2016 06:44 AM, Andrew Dunstan wrote:
Here is a patch to add enum support to btree_gin and btree_gist. I didn't
include distance operations, as I didn't think it terribly
On 03/20/2016 12:02 AM, Michael Paquier wrote:
On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote:
Still to do: the non-perl pieces.
The patch to address locales is the sensitive part. The patch from
Petr is taking the correct approach though I think that we had better
simplify it a bit
t once I did it was pretty much plain sailing.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
27;m going to have to trust the two of
you (Michael and Petr) that this works. Will either of you be setting up
a buildfarm animal with VS2015?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/25/2016 04:13 AM, Matthias Kurz wrote:
Hopefully at the commitfest at least the transaction limitation
will/could be tackled - that would help us a lot already.
I don't believe anyone knows how to do that safely. Enums pose special
problems here exactly because unlike all other ty
ance operator support for numeric.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/25/2016 03:22 PM, Christophe Pettus wrote:
On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote:
I don't believe anyone knows how to do that safely.
The core issue, for me, is that not being able to modify enum values in a
transaction breaks a very wide variety of database migr
On 03/26/2016 12:35 AM, David G. Johnston wrote:
On Friday, March 25, 2016, Andrew Dunstan <mailto:and...@dunslane.net>> wrote:
On 03/25/2016 04:13 AM, Matthias Kurz wrote:
Hopefully at the commitfest at least the transaction
limitation will/could be tackl
On 03/26/2016 10:25 AM, Tom Lane wrote:
Andrew Dunstan writes:
We don't have the luxury of being able to redesign this as a green
fields development.
I'm not actually convinced that we need to do anything. SQL already has a
perfectly good mechanism for enforcing that a column con
On 03/27/2016 12:43 AM, Christophe Pettus wrote:
On Mar 26, 2016, at 7:40 AM, Andrew Dunstan wrote:
It would be nice if we could find a less broad brush approach to dealing with
the issue.
I don't know how doable this is, but could we use the existing mechanism of
marking an index in
In that case I humbly submit that there is a case for reviving the psql
patch I posted that kicked off this whole thing and lets you export a
piece of binary data from psql quite easily. It should certainly not
involve any protocol break.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/28/2016 11:18 PM, Pavel Stehule wrote:
Anyway this is certainly not committable as-is, so I'm setting
it back
to Waiting on Author. But the fact that both libpq and ecpg
would need
updates makes me question whether we can safely pretend that
On 03/27/2016 10:20 AM, Tom Lane wrote:
Andrew Dunstan writes:
The more I think about this the more I bump up against the fact that
almost anything we do might want to do to ameliorate the situation is
going to be rolled back. The only approach I can think of that doesn't
suffer from th
0004 though.
I think it would be a shame if we shipped 9.6 without MSVC 2015
support, but it'd be nice if Andrew or Magnus could do the actual
committing, 'cuz I really don't want to be responsible for breaking
the Windows build.
I'm fine to back you up as needed. That's
grade?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I do think it makes life easier when going through the git history if
semantic changes are separated from formatting changes.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t?
So "arraycol[2]" is not possible there.
I think the idea here was that it's allowed in UPDATE. But I don't
see the point of allowing that in an INSERT.
Right. Why not just forbid anything other than a plain column name on
the LHS for INSERT, at least as a fi
some investigation from Andrew that cygwin does
not need to use the service-related code, aka register/unregister
options or similar that are proper to WIN32 and rely instead on
cygrunsrv with a SYSV-like init file to manage the service. Based on
my tests with cygwin, I am able to see as well that a server st
On 01/18/2016 12:38 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I think we can be a bit more adventurous and remove all the Cygwin-specific
code. See attached patch, which builds fine on buildfarm cockatiel.
Hopefully you also tested that it builds under MSVC :-)
Why would I? This
On 01/18/2016 03:46 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
On 01/18/2016 12:38 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I think we can be a bit more adventurous and remove all the Cygwin-specific
code. See attached patch, which builds fine on buildfarm cockatiel
//idallen.com/topposting.html>>
2. You've done all you need to do. We'll take care of it. Thanks for the
report.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
many thanks to CommandPrompt for their constant support over the
many years we've been in operation.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/18/2016 05:20 PM, Andrew Dunstan wrote:
People,
Apologies for the late notice.
Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we
will be moving the buildfarm server from its current home at
CommandPrompt, where we have been ever since we started, to a machine
that
builds are discussed (section 15.4
http://www.postgresql.org/docs/9.5/static/install-procedure.html )
jacana does VPATH builds with pretty much this setup all the time. See
for example
<http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jacana&dt=2016-01-19%2013%3A00%3A09>
cheers
On 01/19/2016 02:01 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
jacana does VPATH builds with pretty much this setup all the time. See for
example
<http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jacana&dt=2016-01-19%2013%3A00%3A09>
Yes, it builds a tree *once*, then d
ation next week.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is the limit on subject size. Sometimes it's very difficult to be
sufficiently communicative in, say, 50 characters.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he hashtable idea if it can be made workable.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t entirely clear how well this will
match up with, say, plperl, but I'd be interested to see.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er idea for data to collect?
I think that's an excellent idea. This has been a minor running sore for
ages on slow machines.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi, hackers!
I want to propose improvement of GiST page layout.
GiST is optimized to reduce disk operations on search queries, for
example, windows search queries in case of R-tree.
I expect that more complicated page layout will help to tradeoff some
of CPU efficiency for disk efficiency.
GiST
_ctl answer
to an environment variable once we've done that.
The failure on axolotl was for the ECPG tests, which don't use the
buildfarm's startup/stop db code. They don't honour TEMP_CONFIG either,
which they probably should - then we might get better log traces.
cheers
an
something on grounds of helping the buildfarm, so I find
that argument pretty weak.
OK. I can put out a new release as required.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/09/2016 05:53 PM, Tom Lane wrote:
Andrew, I wonder if I could prevail on you to make axolotl run "make
check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can
see if the logging I added tells anything useful about this.
Will d
On 02/09/2016 06:46 PM, Andrew Dunstan wrote:
On 02/09/2016 05:53 PM, Tom Lane wrote:
Andrew, I wonder if I could prevail on you to make axolotl run "make
check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can
see if the logging I added tells anything useful
On 02/09/2016 07:49 PM, Tom Lane wrote:
Andrew Dunstan writes:
So running it's not running with fsync off or using the ramdisk for
stats_temp_directory. Of course, that doesn't explain why we're not
seeing it on branches earlier than 9.5, but it could explain why we're
o
On 02/09/2016 08:49 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/09/2016 07:49 PM, Tom Lane wrote:
However, I'd already noted from some other digging in the buildfarm
logs that axolotl's speed seems to vary tremendously. I do not
know what else you typically run on that har
I'm not sure how to prove
such a theory from here.
Yeah. It's faintly possible that a kernel upgrade will help.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/09/2016 11:21 PM, Andrew Dunstan wrote:
The idea I was toying with is that previous filesystem activity (making
the temp install, the server's never-fsync'd writes, etc) has built up a
bunch of dirty kernel buffers, and at some point the kernel goes nuts
writing all that
On 02/10/2016 12:53 PM, Tom Lane wrote:
Andrew Dunstan writes:
Yeah. It's faintly possible that a kernel upgrade will help.
Another data point. I have another RPi2B that is running Debian Wheezy
rather than the Fedora remix. I'm running the same test on it we ran
yesterday on a
tests the buildfarm ran
using a temp install. That wasn't even available for contrib and the
PLs, IIRC.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hink I can live quite happily with it being superuser only. It's pretty
hard to argue that exposing it to a superuser creates much risk, ISTM.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
> '120',
to the build_env stanza of your config file should do the trick, and you
can happily wait for the next release.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
found a case where using btree exclusion constraints was
useful: a unique index on an expression can't be marked deferrable, but
the equivalent exclusion constraint can be.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the only
case which is valid in both C and C++ where this makes a difference.)
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n, Octonica & Ural Federal University.
2016-08-16 20:23 GMT+05:00 Anastasia Lubennikova :
> 09.08.2016 19:45, Andrew Borodin:
>>
>> Here is new version of the patch, now it includes recommendations from
>> Anastasia Lubennikova.
>>
>>
>> I've invest
s quite surprisingly slow; ip4r
beats it into the ground without difficulty. (I'd be curious how well
this sp-gist version stacks up against ip4r.)
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e that if the lefttree doesn't
have any parameter changes then it suffices to re-project the data from
the existing hashtable; but of course this is nonsense if the parameter
is in an input to an aggregate function.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hac
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Andrew&g
enerate_series(1,3) y group by y)
Tom> from generate_series(1,3) x;
Tom> and we'd be losing some efficiency for cases like that if we fix
Tom> it as above. But is it worth the trouble?
The loss of efficiency could be significant, since it's forcing a rescan
of what could be an
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not.
How about:
--
Andrew (irc:Rhodi
>>>>> "Pavel" == Pavel Stehule writes:
Pavel> The result should not depend on GUC - hashagg on/off changing
Pavel> output - it is error.
I don't think anyone's suggesting leaving it unfixed, just whether the
fix should introduce unnecessary re
h. We don't need to
Tom> recalculate for Params in aggdirectargs, do we?
In theory we would need to. But in practice we don't, because we don't
allow ordered aggs in AGG_HASHED mode anyway.
We could skip filling in aggParam at all if not in AGG_HASHED mode I
guess.
--
Andrew
Hi, hackers!
Some time ago I put a patch to commitfest that optimizes slightly GiST
inserts and updates. It's effect in general is quite modest (15% perf
improved), but for sorted data inserts are 3 times quicker. This
effect I attribute to mitigation of deficiencies of old split
algorithm.
Alexa
Hi hackers!
Here is the new patch version.
With the help of Mikhail Bakhterev I've optimized subroutines of the
penalty function. Index build time now is roughly equivalent to build
time before patch (test attached to thread start).
Time of SELECT statement execution is reduced by 40%.
Changes in
Thank you for your coments, Tom.
> Modern compilers are generally able to make their own decisions about it, and
> trying to put your thumb on the scales this heavily is not likely to improve
> the code.
Well, I have tested that combination of "static inline" affets
performance of index build on
Here is new version of the patch.
Now function pack_float is commented better.
All inline keywords are removed. I haven't found any performance loss for that.
Remove of static's showed 1%-7% performance loss in SELECT computation
(3 test runs), so I left statics where they are.
Actually, to avoid
1 - 100 of 10127 matches
Mail list logo
