Hi,
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de 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
Andres Freund and...@anarazel.de 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
Hi,
On 06/10/2009 01:38 PM, Gregory Stark wrote:
Andres Freundand...@anarazel.de 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
Andres Freund and...@anarazel.de 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
Hi,
On 06/10/2009 06:01 PM, Kevin Grittner wrote:
Andres Freundand...@anarazel.de 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
Hi,
While analyzing some complex query and switching away from using the
materialized views to their underlying ones I got interested in the long
plan times (minutes and up) and did some profiling work.
The queries are high dimensional star-schema-alike queries
(unfortunately quite private
Andres Freund and...@anarazel.de 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
Hi,
On 06/03/2009 06:21 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de 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
Andres Freund and...@anarazel.de 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
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de 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?
Andres Freund and...@anarazel.de 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!)
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andres Freund and...@anarazel.de 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
Gregory Stark st...@enterprisedb.com 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
Gregory Stark st...@enterprisedb.com 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
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Gregory Stark st...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On 06/03/2009 07:05 PM, Kevin Grittner wrote:
Andres Freundand...@anarazel.de 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
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
Greg Stark greg.st...@enterprisedb.com 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
On 06/03/2009 08:57 PM, Gregory Stark wrote:
Kevin Grittnerkevin.gritt...@wicourts.gov writes:
Andres Freundand...@anarazel.de 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
On 06/03/2009 10:42 PM, Kevin Grittner wrote:
Robert Haasrobertmh...@gmail.com 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
On Wed, Jun 3, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
24 matches
Mail list logo
