2015-07-09 22:34 GMT+02:00 Nicolas Paris :
> 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 comp
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 (redond
On Thu, Jul 9, 2015 at 5:20 AM, Nicolas Paris 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 merge join on a i
On 09 Jul 2015, at 17:42, Merlin Moncure 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 life.
But still -
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 matte
On Thu, Jul 9, 2015 at 10:12 AM, Graeme B. Bell 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 improve
>> 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 th
>>
>> 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 li
On 09 Jul 2015, at 15:22, Thomas Kellerer 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.
>
> From: http:/
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 wrote:
> On 09 Jul 2015, at 05:38, Tom Lane 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
On Wed, Jul 8, 2015 at 5:38 PM, Craig James wrote:
> On Wed, Jul 8, 2015 at 1:27 PM, Andres Freund wrote:
>>
>> On 2015-07-08 13:46:53 -0500, Merlin Moncure wrote:
>> > On Wed, Jul 8, 2015 at 12:48 PM, Craig James
>> > wrote:
>> > > On Tue, Jul 7, 2015 at 10:31 PM, Joshua D. Drake
>> > >
>> > >
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 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 r
On 08 Jul 2015, at 13:20, Andres Freund 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 the same prob
On 09 Jul 2015, at 05:38, Tom Lane 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 huge difference
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 08 Jul 2015, at 22:27, Andres Freund wrote:
> On 2015-07-08 13:46:53 -0500, Merlin Moncure wrote:
>> On Wed, Jul 8, 2015 at 12:48 PM, Craig James wrote:
>>>
>>> Well, right, which is why I mentioned "even with dozens of clients."
>>> Shouldn't that scale to at least all of the CPUs in use if
18 matches
Mail list logo
