> wxd0812=# EXPLAIN ANALYZE
> wxd0812-# SELECT * FROM
> wxd0812-# (SELECT DISTINCT ON (key1_id,key2_id) * FROM sid120.data
> ORDER BY key1_id,key2_id,time_id DESC) x
> wxd0812-# WHERE NOT deleted;
SELECT * FROM (
SELECT data.*,
rank() as rank over
( partition by key1_id,
Bruce Momjian wrote:
We recomment 'data=writeback' for ext3 in our docs
Only for the WAL though, which is fine, and I think spelled out clearly
enough in the doc section you quoted. Ken's system has one big RAID
volume, which means he'd be mounting the data files with 'writeback'
too; th
Greg Smith wrote:
> > 2) Should I configure the ext3 file system with noatime and/or
> > data=writeback or data=ordered? My controller has a battery, the
> > logical drive has write cache enabled (write-back), and the physical
> > devices have write cache disabled (write-through).
>
> data=ord
List,
I see benefits to using the 8.4 WINDOW clause in some cases but I'm having
trouble seeing if I could morph the following query using it.
wxd0812=# EXPLAIN ANALYZE
wxd0812-# SELECT * FROM
wxd0812-# (SELECT DISTINCT ON (key1_id,key2_id) * FROM sid120.data ORDER BY
key1_id,key2_id,time_id DES
Unfortunately I had double-posted this - originally in General.
Tom Lane pointed out (in PG-GENERAL) that the planner will take any IN
(SELECT...) statement and do a JOIN, which is what is causing the planner
problem - even though the SELECT was just returning a constant. Obviously,
the real query
"Carlo Stonebanks" wrote:
> SELECT *
> FROM mdx_core.vw_provider AS p
> WHERE provider_id IN (SELECT 13083101)
>
> I am using the simple IN (SELECT n) in QUERY 2 to simplify the
> problem. I noticed the oddity of the behaviour when I used a
> proper "IN (SELECT myId FROM myTable)"
Did you try
