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
[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
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
FROM pets
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 WHERE zipcode =
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:
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, we
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
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:
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 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
that pop up.
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',
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 visited
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
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
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 have
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
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
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
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
19 matches
Mail list logo
