Hi,
On 06/10/2009 06:01 PM, Kevin Grittner wrote:
Andres Freund wrote:
- Sometimes adding a single join more/less dropped the planning time
to a fraction - strange.
- The same with changing {join,from}_collapse_limit - sometimes
changing it yields plan times different by orders of magnitudes i
Andres Freund wrote:
> - Sometimes adding a single join more/less dropped the planning time
> to a fraction - strange.
> - The same with changing {join,from}_collapse_limit - sometimes
> changing it yields plan times different by orders of magnitudes in
> both directions.
That seems like the p
Hi,
On 06/10/2009 01:38 PM, Gregory Stark wrote:
Andres Freund writes:
Plan time (averaged) without change:
cnt: 40 (4 times per session)
avg: 4572ms
Plan time (averaged) with change:
cnt: 40 (4 times per session)
avg: 4236ms
~7% difference. Same with higher number of repetitions and with m
Andres Freund writes:
> Plan time (averaged) without change:
> cnt: 40 (4 times per session)
> avg: 4572ms
>
> Plan time (averaged) with change:
> cnt: 40 (4 times per session)
> avg: 4236ms
>
> ~7% difference. Same with higher number of repetitions and with most other
> planner settings I tried
Hi,
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freund writes:
On 06/03/2009 06:21 PM, Tom Lane wrote:
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles. What sort of
queries are you testing?
Many left joins
On Wed, Jun 3, 2009 at 5:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
>> wrote:
>>> I'm finding that even the ones that had a plan time in the range of
>>> 260 ms go down to 15 ms to 85 ms once the statistics are cached.
>
>> I had some performan
On 06/03/2009 10:42 PM, Kevin Grittner wrote:
Robert Haas wrote:
When you say, "don't fit in cache", exactly what
cache are you talking about? It seems to me that the statistics
should be far smaller than the underlying tables, so if even your
statistics don't fit in shared buffers (let alone
On 06/03/2009 08:57 PM, Gregory Stark wrote:
"Kevin Grittner" writes:
Andres Freund wrote:
long plan times (minutes and up)
Wow. I thought I had some pretty complex queries, including some
which join using several views, each of which has several joins;
but I've never gone to multiple secon
Greg Stark writes:
> It does seem like it ought to be possible to truncate strings in the
> histogram since any string between the actual values us equally good.
Yeah, that was the justification for dropping the wide values ---
that and the theory that they'd be unlikely to be most-common value
Doesn't that still add up to 3GB for a table's stats in the worst
case? 1kb * 1,000 buckets * 1,500 attributes * 2 (histogram + mfv)
Except you can't actually get 1500 toast pointers on a page. I suppose
with games with nulls you could make this worst case happen though.
It does seem like i
On 06/03/2009 07:05 PM, Kevin Grittner wrote:
Andres Freund wrote:
long plan times (minutes and up)
Wow. I thought I had some pretty complex queries, including some
which join using several views, each of which has several joins; but
I've never gone to multiple seconds on plan time (much le
Robert Haas writes:
> On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
> wrote:
>> I'm finding that even the ones that had a plan time in the range of
>> 260 ms go down to 15 ms to 85 ms once the statistics are cached.
> I had some performance results back when we were last looking at
> default_st
"Kevin Grittner" writes:
> Since he can't share the schema, and hasn't even given much of a hint,
> I don't know whether one (or more) of the columns is a bytea filled
> with 100 MB values; and I don't remember any description of the
> hardware environment either. Since the behavior seems so
> ou
Robert Haas wrote:
> When you say, "don't fit in cache", exactly what
> cache are you talking about? It seems to me that the statistics
> should be far smaller than the underlying tables, so if even your
> statistics don't fit in shared buffers (let alone main memory), it
> doesn't really matt
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
wrote:
> Gregory Stark wrote:
>
>> My money's still on very large statistics targets. If you have a lot
>> of columns and 1,000-element arrays for each column that can get big
>> pretty quickly.
>
> I'm finding that even the ones that had a plan time
Gregory Stark wrote:
> My money's still on very large statistics targets. If you have a lot
> of columns and 1,000-element arrays for each column that can get big
> pretty quickly.
I'm finding that even the ones that had a plan time in the range of
260 ms go down to 15 ms to 85 ms once the st
Gregory Stark writes:
> But that doesn't explain the bitmap ops being important. Hm. Actually
> having a lot of columns and then joining a lot of tables could mean
> having fairly large bitmapsets.
Yeah, but then you have a lot of *other* expensive operations too,
such as the aforementioned stati
"Kevin Grittner" writes:
> Andres Freund wrote:
>
>> long plan times (minutes and up)
>
> Wow. I thought I had some pretty complex queries, including some
> which join using several views, each of which has several joins; but
> I've never gone to multiple seconds on plan time (much less mu
Andres Freund wrote:
> long plan times (minutes and up)
Wow. I thought I had some pretty complex queries, including some
which join using several views, each of which has several joins; but
I've never gone to multiple seconds on plan time (much less multiple
minutes!) without very high stati
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freund writes:
On 06/03/2009 06:21 PM, Tom Lane wrote:
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles. What sort of
queries are you testing?
Many left joins fro
Andres Freund writes:
> On 06/03/2009 06:21 PM, Tom Lane wrote:
>> I find this *really* hard to believe, because I've never seen the bitmap
>> support operations show up noticeably at all in profiles. What sort of
>> queries are you testing?
> Many left joins from one base relation to additional
Hi,
On 06/03/2009 06:21 PM, Tom Lane wrote:
Andres Freund writes:
When switching bitmapword and companions in bitmap.h to u64 and s64
respectively I get an improvement up to 15% in queries with 16+ joins.
I find this *really* hard to believe, because I've never seen the bitmap
support operati
Andres Freund writes:
> When switching bitmapword and companions in bitmap.h to u64 and s64
> respectively I get an improvement up to 15% in queries with 16+ joins.
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles.
23 matches
Mail list logo
