On Fri, Aug 26, 2005 at 10:45:07AM -0400, Alan Stange wrote:
- Bitmap Heap Scan on tbltimeseries (cost=48714.09..1331000.42
rows=10854026 width=8)
Recheck Cond: (timeseriesid 0)
- Bitmap Index Scan on idx_timeseris (cost=0.00..48714.09
rows=10854026
Alan Stange [EMAIL PROTECTED] writes:
Unique (cost=2717137.08..2771407.21 rows=10854026 width=8)
- Sort (cost=2717137.08..2744272.14 rows=10854026 width=8)
Sort Key: timeseriesid
- Bitmap Heap Scan on tbltimeseries
(cost=48714.09..1331000.42 rows=10854026 width=8)
I would like to know if the following kind of database client exists: I need a
'select' query to be sent to say 10 db servers simultaneously in parallel
(using threading), the results should be re-sorted and returned. For example I
have a query: 'select * from table where parent_clname =
Mark Kirkwood [EMAIL PROTECTED] writes:
What is interesting is why this plan is being rejected...
Which PG version are you using exactly? That mistake looks like an
artifact of the 8.0 fuzzy plan cost patch, which we fixed recently:
Hello all,
I was hoping someone could explain the plan for a statement.
We have a table with a column of longs being used as an index. The
query plan in 8.0 was like this:
# explain select distinct timeseriesid from tbltimeseries where
timeseriesid 0 order by timeseriesid;
I had the
On Fri, 26 Aug 2005 20:54:09 +0530
Ligesh [EMAIL PROTECTED] wrote:
I would like to know if the following kind of database client exists:
I need a 'select' query to be sent to say 10 db servers
simultaneously in parallel (using threading), the results should be
re-sorted and returned.
Does such a solution exist now. To me this appears to be in entirety
of
what should constitute a database cluster. Only the search needs to be
done on all the servers simultaneously at the low level. Once you get
the
results, the writing can be determined by the upper level logic (which
can
On Wed, Aug 24, 2005 at 07:42:00PM -0400, Tom Lane wrote:
Mark Fox [EMAIL PROTECTED] writes:
The sort of queries I want to execute (among others) are like:
SELECT * FROM jobs
WHERE completion_time SOMEDATE AND start_time SOMEDATE;
In plain english: All the jobs that were running at
Well folks, I've been trying to track down why this Athlon 2800
(2.1ghz) has been handing my 2.5ghz G5 its cake. I have a query that
(makes no io - the dataset can live in ram easily) takes about 700ms
on the athlon and about 10 seconds on the G5.
Tracking ti down a bit
Tom Lane wrote:
Alan Stange [EMAIL PROTECTED] writes:
Unique (cost=2717137.08..2771407.21 rows=10854026 width=8)
- Sort (cost=2717137.08..2744272.14 rows=10854026 width=8)
Sort Key: timeseriesid
- Bitmap Heap Scan on tbltimeseries
(cost=48714.09..1331000.42
Hopefully a quick question.
In 7.3.4, how does the planner execute a query with union alls in it?
Does it execute the unions serially, or does it launch a thread for
each union (or maybe something else entirely).
Thanks,
Chris
Here is an explain from the view I'm thinking about, how does
On Fri, Aug 26, 2005 at 16:14:18 -0400,
Chris Hoover [EMAIL PROTECTED] wrote:
Hopefully a quick question.
In 7.3.4, how does the planner execute a query with union alls in it?
Does it execute the unions serially, or does it launch a thread for
each union (or maybe something else
Jim C. Nasby [EMAIL PROTECTED] writes:
Uh, the plain english and the SQL don't match. That query will find
every job that was NOT running at the time you said.
No, I think it was right. But anyway it was just an example.
On Wed, Aug 24, 2005 at 07:42:00PM -0400, Tom Lane wrote:
AFAIK there
On 26-8-2005 15:05, Richard Huxton wrote:
Arjen van der Meijden wrote:
I left all the configuration-stuff to the defaults since changing
values didn't seem to impact much. Apart from the buffers and
effective cache, increasing those made the performance worse.
I've not looked at the rest
Hello,
We are using PostgreSQL for our business application. Recently, during
testing of our application with large volumes of data, we faced a weird
problem. Our query performance dropped *dramatically* after VACUUM FULL
ANALYZE command. We have encountered a similar problem listed on
mailing
On Fri, Aug 26, 2005 at 11:04:59AM -0500, Frank Wiles wrote:
On Fri, 26 Aug 2005 20:54:09 +0530
This is typically handled by the application layer, not a standard
client. Mostly because every situation is different, you may have
10 servers and need 10 rows of results, others may need
On Fri, Aug 26, 2005 at 11:04:59AM -0500, Frank Wiles wrote:
On Fri, 26 Aug 2005 20:54:09 +0530
Ligesh [EMAIL PROTECTED] wrote:
Mostly because every situation is different, you may have
10 servers and need 10 rows of results, others may need something
entirely different.
No. I
Hi,
I have the same issue. After doing VACCUME ANALYZE
performance of the query dropped.
Here is the query
explain select * from conversion_table c where
c.conversion_date BETWEEN '2005-06-07' and
'2005-08-17'
Before VACCUME ANALYZE
Index Scan using conversion_table_pk on
Arjen van der Meijden [EMAIL PROTECTED] writes:
As said, it chooses sequential scans or the wrong index plans over a
perfectly good plan that is just not selected when the parameters are
too well tuned or sequential scanning of the table is allowed.
I think some part of the problem comes
Hi,
I have the same issue. After doing VACCUME ANALYZE
performance of the query dropped.
Here is the query
explain select * from conversion_table c where
c.conversion_date BETWEEN '2005-06-07' and
'2005-08-17'
Before VACCUME ANALYZE
Index Scan using conversion_table_pk on
On Fri, Aug 26, 2005 at 03:52:24PM -0700, asif ali wrote:
I have the same issue. After doing VACCUME ANALYZE
performance of the query dropped.
Your EXPLAIN output doesn't show the actual query times -- could
you post the EXPLAIN ANALYZE output? That'll also show how accurate
the planner's row
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
What is interesting is why this plan is being rejected...
Which PG version are you using exactly? That mistake looks like an
artifact of the 8.0 fuzzy plan cost patch, which we fixed recently:
=?ISO-8859-1?Q?=DCmit_=D6ztosun?= [EMAIL PROTECTED] writes:
We are using PostgreSQL for our business application. Recently, during
testing of our application with large volumes of data, we faced a weird
problem. Our query performance dropped *dramatically* after VACUUM FULL
ANALYZE command.
I
Mark Kirkwood [EMAIL PROTECTED] writes:
That doesn't explain why the nested loop is being kicked tho',
No, but I think the fuzzy-cost bug does. There are two different issues
here.
regards, tom lane
---(end of
Thanks Michael For your reply.
Here is performance on the database on which i did
VACUUM ANALYZE
explain analyze
select keyword_id
,sum(daily_impressions) as daily_impressions
,sum(daily_actions)as daily_actions
from conversion_table c wherec.conversion_date
BETWEEN
On Fri, Aug 26, 2005 at 05:10:49PM -0700, asif ali wrote:
GroupAggregate (cost=195623.66..206672.52 rows=20132
width=16) (actual time=8205.283..10139.369 rows=55291
loops=1)
- Sort (cost=195623.66..198360.71 rows=1094820
width=16) (actual time=8205.114..9029.501 rows=863883
loops=1)
Interestingly enough, 7.4.8 and 8.1devel-2005-08-23 all behave the same
as 8.0.3 for me (tables freshly ANALYZEd):
joinlimit=# SELECT version();
version
Tom Lane [EMAIL PROTECTED] writes:
As far as the desc point goes, the problem is that mergejoins aren't
capable of dealing with backward sort order, so a merge plan isn't
considered for that case (or at least, it would have to have a sort
after it, which pretty much defeats the point for a
The first, to always remember - is that the move from 64-bits to
32-bits doesn't come for free. In a real 64-bit system with a
64-bit operating system, and 64-bit applications, pointers are
now double their 32-bit size. This means more bytes to copy around
memory, and in an extreme case, has
Hi.
The company that I'm working for are surveying the djungle of DBMS
since we are due to implement the next generation of our system.
The companys buissnes is utilizing the DBMS to store data that are
accessed trough the web at daytime (only SELECTs, sometimes with joins,
etc). The data is a
I've read that
indexes aren't used for COUNT(*) and I've noticed (7.3.x) with EXPLAIN that
indexes never seem to be used on empty tables - is there any reason to have
indexes on empty tables, or will postgresql never use them.
This is not as silly
as it sounds - with table inheritance you
Hi Chris.
Thanks for the answer.
Sorry that i was a bit unclear.
1) We update around 20.000 posts per night.
2) What i meant was that we suspect that the DBMS called PervasiveSQL
that we are using today is much to small. That's why we're looking for
alternatives.
Today we base our solution
32 matches
Mail list logo
