Greg Stark [EMAIL PROTECTED] writes:
The now() BETWEEN test_table_1.start_ts AND test_table_1.end_ts can't be
answered completely using a btree index. You could try using a GIST index here
but I'm not clear how much it would help you (or how much work it would be).
To add to my own comment
Hi,
I have two tables:
Customer: objectid, lastname, fk_address
Address: objectid, city
I want to select all customers with a name = some_name and living in a city = some_city, all comparisons case insensitive
Below is what I actually have. Given the fact that it takes forever to get a
On 3/4/06, Joost Kraaijeveld [EMAIL PROTECTED] wrote:
Below is what I actually have. Given the fact that it takes forever to get
a result ( 6 seconds) , there must be something wrong with my solution or
my expectation. Can anyone tell what I should do to make this query go
faster ( or
Hi Hubert,
On Sat, 2006-03-04 at 14:49 +0100, hubert depesz lubaczewski wrote:
Sort (cost=54710.68..54954.39 rows=97484 width=111) (actual
time=7398.971..7680.405 rows=96041 loops=1)
Sort Key: btrim(upper(customers.lastname)), btrim(upper(addresses.city))
- Hash Join
On 3/4/06, Joost Kraaijeveld [EMAIL PROTECTED] wrote:
how many record do you have in the customers table?
368915 of which 222465 actually meet the condition.
From what I understand from the mailing list, PostgreSQL prefers a table
scan whenever it expects that the number of records in the
On Sat, Mar 04, 2006 at 02:01:35AM -0500, Greg Stark wrote:
Alex Adriaanse [EMAIL PROTECTED] writes:
SELECT count(*) FROM test_table_1
INNER JOIN test_table_2 ON
(test_table_2.s_id = 13300613 AND test_table_1.id =
test_table_2.n_id)
WHERE now() BETWEEN
Greg Stark [EMAIL PROTECTED] writes:
(I don't think the end_ts in the index is buying you much, despite its
appearance in the Index Cond in the plan.)
Well, it saves some trips to the heap, but the indexscan is still going
to run from the beginning of the index to start_ts = now(), because
Tom Lane [EMAIL PROTECTED] writes:
Otherwise I think you really need a special datatype for time
intervals and a GIST or r-tree index on it :-(.
You could actually take short cuts using expression indexes to do this. If it
works out well then you might want to implement a real data type to
On Saturday 04 March 2006 08:23, hubert depesz lubaczewski wrote:
On 3/4/06, Joost Kraaijeveld [EMAIL PROTECTED] wrote:
how many record do you have in the customers table?
368915 of which 222465 actually meet the condition.
From what I understand from the mailing list, PostgreSQL
