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
);
C
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 be
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
(network_events.name='b
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
re
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-man
> 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 no
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 othe
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