Mark Stosberg <[EMAIL PROTECTED]> writes:
> For reference, here's two versions of the query. The first uses
> the old geo_distance(), and the second one is the new cube query I'm
> trying, inspired by your suggested refactoring.
You didn't show EXPLAIN ANALYZE output :-(
Looking back in the thre
Dan Harris wrote:
Arjen van der Meijden wrote:
But be aware that there can be substantial and unexpected differences
on this relatively new platform due to simply changing the OS, like we
saw when going from linux 2.6.15 to 2.6.18, as you can see here:
http://tweakers.net/reviews/657/2
Havi
Dan,
On 2/13/07, Dan Harris <[EMAIL PROTECTED]> wrote:
Having upgraded to 2.6.18 fairly recently, I am *very* interested in
what caused the throughput to drop in 2.6.18? I haven't done any
benchmarking on my system to know if it affected my usage pattern
negatively, but I am curious if anyone k
Arjen van der Meijden wrote:
But be aware that there can be substantial and unexpected differences on
this relatively new platform due to simply changing the OS, like we saw
when going from linux 2.6.15 to 2.6.18, as you can see here:
http://tweakers.net/reviews/657/2
Having upgraded to 2
Kenji Morishige wrote:
Please comment on any issues you may see with this box and my assumptions.
Also any FreeBSD kernel issues or tweaks you could recommend.
I would recommend posting to freebsd-hardware or freebsd-stable and
asking if there are any gotchas with the X7DBE+ and 6.2 (for ins
Hi Kenji,
On 13-2-2007 20:46 Kenji Morishige wrote:
Here is the full specification of the new box I hope to build and run FreeBSD
6.X and PostgreSQL on:
- SuperMicro Dual Xeon X7DBE+ motherboard
+ 2 x Quad Core X5355 2.66Ghz
OR
+ 2 x Dual Core 5160 3.0Ghz
- 8 x 1GB PC2-4200 fully bu
On Tue, Feb 13, 2007 at 09:31:18AM -0500, Merlin Moncure wrote:
>
> >my mistake, i misunderstood what you were trying to do...can you try
> >removing the 'order by radius' and see if it helps? if not, we can try
> >working on this query some more. There is a better, faster way to do
> >this, I'm s
"Chuck D." <[EMAIL PROTECTED]> writes:
> It is still using that sequence scan on the view after the APPEND for the
> us_city and world_city table. Any reason why the view won't use the indexes
> when it is JOINed to another table but it will when the view is queried
> without a JOIN? I should
On Tuesday 13 February 2007 13:16, Merlin Moncure wrote:
>
> use 'union all' instead of union. union without all has an implied
> sort and duplicate removal step that has to be resolved, materializing
> the view, before you can join to it.
>
Thanks for that Merlin, I forgot about using ALL. That
I am about to pull the trigger on a new machine after analyzing some
discussions I posted here last year. I've been trying to spec out a reliable
and powerfull enough machine where I won't have to replace it for some time.
Currently I've been using a dual Xeon 3.06ghz with 4GB of ram and utilizing
On 2/13/07, Chuck D. <[EMAIL PROTECTED]> wrote:
Hi folks,
I don't know if this is an SQL or PERFORMANCE list problem but I wanted to
check here first. I've seen this discussed on the list before but I'm still
not sure of the solution. Maybe my query is just structured wrong.
I recently visite
Hi folks,
I don't know if this is an SQL or PERFORMANCE list problem but I wanted to
check here first. I've seen this discussed on the list before but I'm still
not sure of the solution. Maybe my query is just structured wrong.
I recently visited an old project of mine that has a 'city', 'sta
On Tuesday 13 February 2007 10:36, "Campbell, Lance" <[EMAIL PROTECTED]>
wrote:
> We have 12+ schemas in 1 database. When I do a unix "top" command I
> notice one postmaster process has 100% CPU usage. This process just
> stays at 100% to 99% CPU usage. There are other postmaster processes
> tha
Postgres 8.1
Linux Redhat AS 4.X
4 processor box
We have 12+ schemas in 1 database. When I do a unix "top" command I
notice one postmaster process has 100% CPU usage. This process just
stays at 100% to 99% CPU usage. There are other postmaster processes
that pop up. They use hardly no CPU or
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> So the basic explanation is that it's in both lists due to the partial
> index and only qpqual keeps the condition? I would have expected the
> opposite but it doesn't change anything I suppose?
It gets the right answer, yes. I'm not sure if we could
On 2/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
bitmapqualorig = list_difference_ptr(bitmapqualorig, qpqual);
What's not immediately clear is why the condition was in both lists to
start with. Perhaps idx_lieu_parking is a partial index with this as
its WHERE condition?
Yes, it is: "idx_l
Hi all,
Following the work on Mark Stosberg on this list (thanks Mark!), I
optimized our slow proximity queries by using cube, earthdistance
(shipped with contrib) and a gist index. The result is globally very
interesting apart for a specific query and we'd like to be able to fix
it too to be mor
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> What surprises me is that "parking" is in the filter and not in the
> Recheck Cond whereas it's part of the second Bitmap Index Scan of the
> Bitmap And node.
That's probably because of this:
/*
* When dealing with special or lossy operators
Hi all,
I'm currently working on optimizing a couple of queries. While
studying the EXPLAIN ANALYZE output of a query, I found this Bitmap
Heap Scan node:
-> Bitmap Heap Scan on lieu l (cost=12.46..63.98 rows=53 width=94)
(actual time=35.569..97.166 rows=78 loops=1)
Recheck Cond: ('(4190964.8
On 2/13/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 2/12/07, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
> >
> >> Here the basic query I'm using:
> >> SELECT
> >> -- 1609.344 is a constant for "meters per mile"
> >> cube_distance( (SELECT earth_coords from zipcodes WHE
On 2/12/07, Mark Stosberg <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
>
>> Here the basic query I'm using:
>> SELECT
>> -- 1609.344 is a constant for "meters per mile"
>> cube_distance( (SELECT earth_coords from zipcodes WHERE zipcode =
>> '90210') , earth_coords)/1609.344
>>AS RADIUS
[EMAIL PROTECTED] wrote:
Now we have a server reserved only for postgresql, and I'm wondering if it
is better to set up:
- only one instance and many databases or
- many instances and only one database/instance or
- one instance, one database and many users
It depends. One instance should give
Hi,
I have used postgresql some years now, but only small databases and only
one database per instance and one user per database.
Now we have a server reserved only for postgresql, and I'm wondering if it
is better to set up:
- only one instance and many databases or
- many instances and only o
23 matches
Mail list logo
