Without index: 1.140 ms
With index: 1.400 ms
With default_statistic_targer = 200: 1.800 ms
Can I just check that 1.800ms means 1.8 secs (You're using . as the
thousands separator)?
If it means 1.8ms then frankly the times are too short to mean
anything without running them 100 times and avera
Richard Huxton wrote:
Gaetano Mendola wrote:
Hi all,
I'm tring to optimize the following query:
http://rafb.net/paste/results/YdO9vM69.html
as you can see from the explain after defining the
index the performance is worst.
If I raise the default_statistic_target to 200
then the performance are wors
Gaetano Mendola wrote:
Hi all,
I'm tring to optimize the following query:
http://rafb.net/paste/results/YdO9vM69.html
as you can see from the explain after defining the
index the performance is worst.
If I raise the default_statistic_target to 200
then the performance are worst then before:
Without
Hi all,
I'm tring to optimize the following query:
http://rafb.net/paste/results/YdO9vM69.html
as you can see from the explain after defining the
index the performance is worst.
If I raise the default_statistic_target to 200
then the performance are worst then before:
Without index: 1.140 ms
With i
Tom,
> This is really interesting. We had previously seen some evidence that
> the Xeon sucks at running Postgres, but I thought that the issues only
> materialized with multiple CPUs (because what we were concerned about
> was the cost of transferring cache lines across CPUs). AFAICS this test
how about:
SELECT distinct main.oid,main.* FROM Tickets main
WHERE main.EffectiveId = main.id
AND main.Status != 'deleted'
AND ( main.Type = 'ticket' OR main.Type = 'subticket' )
AND ( main.Queue = '9' )
AND ( main.id = '17417'
OR main.id IN (
SELECT DISTINCT LocalTarget from Links
where
>From what I can figure, queries like this run much quicker on other
databases, is this something that can be improved ?
Dave
On Thu, 2004-08-19 at 09:38, Brad Bulger wrote:
> You're doing a join except not, is the trouble, looks like. The query is really
> "FROM Tickets main, Links", but when Tic
Brad,
Thanks, that runs on the same order of magnitude as the subqueries.
DAve
On Thu, 2004-08-19 at 09:38, Brad Bulger wrote:
> You're doing a join except not, is the trouble, looks like. The query is really
> "FROM Tickets main, Links", but when Tickets.id is 17417, you've got no join
> to the
You're doing a join except not, is the trouble, looks like. The query is really
"FROM Tickets main, Links", but when Tickets.id is 17417, you've got no join
to the Links table. So you end up getting every row in Links for each row in
Tickets with id = 17417.
I'd think this wants to be two queries o
RT uses a query like:
SELECT distinct main.oid,main.* FROM Tickets main
WHERE
(main.EffectiveId = main.id)
AND
(main.Status != 'deleted')
AND
( (main.Type = 'ticket') OR (main.Type = 'subticket') )
AND
( (main.Queue = '9') )
AND ((
( (Links.Type = 'MemberOf') AND (Links.LocalTarget
Hi,
You asked the very same question yesterday, and I believe you got some useful answers.
Why do you post the question again?
You don't even mention your previous post, and you didn't continue the thread which
you started yesterday.
Did you try out any of the suggestions which you got yesterd
11 matches
Mail list logo
