No, of course it doesn't. It appears that you didn't look at the repo or
read my previous mail before you wrote this.
FFS, I *ran* some of the tests and reported on results. With you in CC.
Just checked back. So you did. I'm sorry, I made the mistake I accused you of.
But... why then
On 09 Jul 2015, at 15:22, Thomas Kellerer spam_ea...@gmx.net wrote:
Graeme B. Bell schrieb am 09.07.2015 um 11:44:
I don't recall seeing a clear statement telling me I should mark pl/pgsql
functions nonvolatile wherever possible or throw all performance and
scalability out the window.
3. I don't disagree that the benchmark code is objectively 'bad' in the
sense that it is missing an important optimisation.
Particularly with regards documentation, a patch improving things is
much more likely to improve the situation than griping. Also,
conversation on this list gets
On Thu, Jul 9, 2015 at 10:12 AM, Graeme B. Bell graeme.b...@nibio.no wrote:
3. I don't disagree that the benchmark code is objectively 'bad' in the
sense that it is missing an important optimisation.
Particularly with regards documentation, a patch improving things is
much more likely to
On 09 Jul 2015, at 17:42, Merlin Moncure mmonc...@gmail.com wrote:
The community maintains it's own mailing list archives in
postgresql.org. Short of an array of tactical nuclear strikes this is
going to be preserved
Good to know, I've seen a lot of dead software projects throughout my
On Thu, Jul 9, 2015 at 5:20 AM, Nicolas Paris nipari...@gmail.com wrote:
Hello,
I wonder how understanding pg_stat_all_indexes working
When I run an explain, some index are not used, but
pg_stat_all_indexes.idx_scan is incremented for those indexes.
When the planner considers using a
On 2015-07-08 23:38:38 -0400, Tom Lane wrote:
and...@anarazel.de (Andres Freund) writes:
On 2015-07-08 15:38:24 -0700, Craig James wrote:
From my admittedly naive point of view, it's hard to see why any of this
matters. I have functions that do purely CPU-intensive mathematical
On 2015-07-09 10:30:35 +, Graeme B. Bell wrote:
Well, that requires reviewing the source code of the run script and
such.
No, of course it doesn't. It appears that you didn't look at the repo or
read my previous mail before you wrote this.
FFS, I *ran* some of the tests and
On 08 Jul 2015, at 22:27, Andres Freund and...@anarazel.de wrote:
On 2015-07-08 13:46:53 -0500, Merlin Moncure wrote:
On Wed, Jul 8, 2015 at 12:48 PM, Craig James cja...@emolecules.com wrote:
Well, right, which is why I mentioned even with dozens of clients.
Shouldn't that scale to at least
Hello,
I wonder how understanding pg_stat_all_indexes working
When I run an explain, some index are not used, but
pg_stat_all_indexes.idx_scan is incremented for those indexes.
Does this mean idx_scan is incremented each time the planner check if an
index could be use whenever it won't use it ?
On 08 Jul 2015, at 13:20, Andres Freund and...@anarazel.de wrote:
On 2015-07-08 11:13:04 +, Graeme B. Bell wrote:
I'm guessing you are maybe pressed for time at the moment because I
already clearly included this on the last email, as well as the links
to the alternative benchmarks with
On 09 Jul 2015, at 05:38, Tom Lane t...@sss.pgh.pa.us wrote:
If you
write your is_prime function purely in plpgsql, and don't bother to mark
it nonvolatile, *it will not scale*.
much for properly written plpgsql; but there's an awful lot of bad plpgsql
code out there, and it can make a
On Wed, Jul 8, 2015 at 5:38 PM, Craig James cja...@emolecules.com wrote:
On Wed, Jul 8, 2015 at 1:27 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-08 13:46:53 -0500, Merlin Moncure wrote:
On Wed, Jul 8, 2015 at 12:48 PM, Craig James cja...@emolecules.com
wrote:
On Tue, Jul 7,
Graeme B. Bell schrieb am 09.07.2015 um 11:44:
I don't recall seeing a clear statement telling me I should mark pl/pgsql
functions nonvolatile wherever possible or throw all performance and
scalability out the window.
From: http://www.postgresql.org/docs/current/static/xfunc-volatility.html
On Thu, Jul 9, 2015 at 4:44 AM, Graeme B. Bell graeme.b...@nibio.no wrote:
On 09 Jul 2015, at 05:38, Tom Lane t...@sss.pgh.pa.us wrote:
If you
write your is_prime function purely in plpgsql, and don't bother to mark
it nonvolatile, *it will not scale*.
much for properly written plpgsql; but
2015-07-09 22:34 GMT+02:00 Nicolas Paris nipari...@gmail.com:
Hello,
My 9.4 database is used as datawharehouse. I can't change the queries
generated.
first index : INDEX COL (A,B,C,D,E)
In case of query based on COL A, the query planner sometimes go to a seq
scan instead of using the
Hello,
My 9.4 database is used as datawharehouse. I can't change the queries
generated.
first index : INDEX COL (A,B,C,D,E)
In case of query based on COL A, the query planner sometimes go to a seq
scan instead of using the first composite index.
The solution is to add a second indexe
This is a reply to to Andreas's post on the #13495 documentation thread in
-bugs.
I am responding to it here because it relates to #13493 only.
Andres wrote, re: #13493
This issue is absolutely critical for performance and scalability of code,
Pft. In most cases it doesn't actually matter
18 matches
Mail list logo
