Hi all,
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
I do the following queries:
espsm_asme=# select customer_app_config_id, customer_app_config_name
from customer_app_config where customer_app_config_id = 5929 or
In response to Arnau [EMAIL PROTECTED]:
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
I do the following queries:
espsm_asme=# select customer_app_config_id, customer_app_config_name
from customer_app_config where
Arnau wrote:
Hi all,
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
You should upgrade. The latest 7.2 release is 7.4.15
I do the following queries:
...
At first glance this looks like a bug in PostgreSQL, but..
Rules:
A lot of
In response to Campbell, Lance [EMAIL PROTECTED]:
If I set work-mem at a particular amount of memory how do I answer the
following questions:
1) How many of my queries were able to run inside the memory I
allocated for work-mem?
2) How many of my queries had to run from disk
Hi Bill,
In response to Arnau [EMAIL PROTECTED]:
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
I do the following queries:
espsm_asme=# select customer_app_config_id, customer_app_config_name
from customer_app_config where
At 06:24 PM 1/28/2007, Josh Berkus wrote:
John,
-work_mem
Depends on the number of concurrent queries you expect to run and what size
sorts you expect them to do.
EXPLAIN ANALYZE is your friend. It will tell you how much data each
query is manipulating and therefore how much memory each
Hello,
I have an authorization table that associates 1 customer IP to a service
IP to determine a TTL (used by a radius server).
table auth
client varchar(15);
service varchar(15);
ttl int4;
client and service are both ip addr.
The number of distinct clients can be rather large (say
* 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 PostgreSQL 8.2, but I could be
mistaken.
Apart from gaining some bytes, would the btree index scan be faster
Nicolas wrote:
I have an authorization table that associates 1 customer IP to a service
IP to determine a TTL (used by a radius server).
table auth
client varchar(15);
service varchar(15);
ttl int4;
client and service are both ip addr.
The number of distinct clients can be rather large
Arnau wrote:
Hi Bill,
In response to Arnau [EMAIL PROTECTED]:
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
I do the following queries:
espsm_asme=# select customer_app_config_id, customer_app_config_name
from customer_app_config
Hi All,
Thanks to all in this support community. You are doing a great job!
With all the information/support from the communities and documentations, we
successfuly upgraded to 8.1 from 7.3.2 on our production environment! It was a
smooth switch over.
Just wanted to say thanks to everyone on
I have partitioned a table based on period (e.g., cdate = '2007-01-01'::date
and cdate=.2007-03-31':;date).
Now, I am issuing query like cdate = CURRENT_DATE - 1 and cdate =
CURRENT_DATE, it scans all the partitions. But if I do cdate =
'2007-01-01'::date and cdate=.2007-03-31'::date it picks
Can anybody help me out
I just wanted to knw what will be the configuraion settings for
partitioning table so as to make inserts faster on the partitioned tables.
Well, that depends. Many questions are important here. Will you insert
into several partitions or only to a single one? Do you
13 matches
Mail list logo
