Hello,
I'm working on setting up replication with Slony, and will soon have a
slave that a lot of SELECT traffic will be sent to (over 500k/day).
The primary query we need to run is somewhat complex, but seems to
complete on average in well under a second.
However, every so often (less in 1 in
I'm needing help determining the best all-around query for the
following situation. I have primary table that holds ip information
and two other tables that hold event data for the specific IP in with
a one-to-many mapping between them, ie:
CREATE TABLE ip_info (
ip IP4,
--other data
);
Michael Artz wrote:
I'm needing help determining the best all-around query for the
following situation.
Not sure whether such a beast exists, but...
I have primary table that holds ip information
and two other tables that hold event data for the specific IP in with
a one-to-many mapping
I've found that doing joins seems to produce better results on the big
tables queries I use. This is not always the case though.
How about this option:
SELECT distinct ip_info.* FROM ip_info RIGHT JOIN network_events USING
(ip) RIGHT JOIN host_events USING (ip) WHERE
How about this option:
SELECT distinct ip_info.* FROM ip_info RIGHT JOIN network_events USING
(ip) RIGHT JOIN host_events USING (ip) WHERE
(network_events.name='blah' OR host_events.name = 'blah') AND
ip_info.ip IS NOT NULL;
Nah, that seems to be much much worse. The other queries usually
On Thu, 1 Feb 2007 11:42:03 -0500
Michael Artz [EMAIL PROTECTED] wrote:
I'm needing help determining the best all-around query for the
following situation. I have primary table that holds ip information
and two other tables that hold event data for the specific IP in with
a one-to-many
I have primary table that holds ip information
and two other tables that hold event data for the specific IP in with
a one-to-many mapping between them, ie:
[snip]
There is quite a bit of commonality between the network_events and
host_events schemas, but they do not currently share an
Michael Artz wrote:
I have primary table that holds ip information
and two other tables that hold event data for the specific IP in with
a one-to-many mapping between them, ie:
[snip]
There is quite a bit of commonality between the network_events and
host_events schemas, but they do not
Here are some numbers for 3 different queries using a very selective
query (port = ). I'm thinking that, since the row estimates are
different from the actuals (2 vs 2000), that this particular port
didn't make it into the statistics ... is that true? Does this
matter? If this isn't enough
On 1/30/07, Pomarede Nicolas [EMAIL PROTECTED] wrote:
On Mon, 29 Jan 2007, Florian Weimer wrote:
* Pomarede Nicolas:
I could use PG internal inet/cidr type to store the ip addrs, which
would take 12 bytes per IP, thus gaining a few bytes per row.
I thought it's down to 8 bytes in
How about this option:
SELECT distinct ip_info.* FROM ip_info RIGHT JOIN network_events USING
(ip) RIGHT JOIN host_events USING (ip) WHERE
(network_events.name='blah' OR host_events.name = 'blah') AND
ip_info.ip IS NOT NULL;
MA Nah, that seems to be much much worse. The other queries
I'm looking to replace some old crusty hardware with some sparkling new
hardware. In the process, I'm looking to move away from the previous
mentality of having the Big Server for Everything to having a cluster of
servers, each of which handles some discrete subset of data. But rackspace
isn't
12 matches
Mail list logo
