Andres Freund wrote:
On 02/03/10 14:42, Robert Haas wrote:
Well, maybe we should start with a discussion of what kernel calls
you're aware of on different platforms and then we could try to put an
API around it.
In linux there is sync_file_range. On newer Posixish systems one can
emulate that w
On Fri, Feb 5, 2010 at 6:17 AM, Yeb Havinga wrote:
> and the cache is used between each row of test_users. The plan is with a
> parameter, that means the optimizer could not make use of an actual value
> during planning. However, your test case is clever in the sense that there
> is an index on us
2010/2/5 Wojtek :
> Most of my queries will have where conditions on timedate and sys_device_id,
> but a lot of them will have additional clause: where usefields is not null.
> Some of the queries will be limited on timedate only.
What about a partial index on (timedate) WHERE usefields IS NOT N
On Fri, Feb 5, 2010 at 4:00 AM, Albe Laurenz wrote:
> Robert Haas wrote:
>> Just for kicks I tried this out and the behavior is as the OP
>> describes: after a little poking around, it sees that the INSERT grabs
>> a share-lock on the referenced row so that a concurrent update can't
>> modify the
2010/2/5 Wojtek
>
> partitions are will typically have from 200k to 300k rows, i have 52
> partitions per year and I'm keeping around 4-5 years of history. However,
> they will query last 3-4 months most often.
>
Do you mean 12 partitions a year or weekly partitions?
> Most of my queries will ha
Dear Postgres Community,
I'm running postgres 8.3
I have a table, partitioned by month
-- Table: datadump
-- DROP TABLE datadump;
CREATE TABLE datadump
(
sys_timestamp timestamp without time zone,
sys_device_id integer,
usefields integer,
timedate timestamp without time zone,
digital
Glenn Maynard wrote:
The function version:
CREATE FUNCTION high_score_for_user(user_id int) RETURNS SETOF INTEGER
LANGUAGE SQL AS $$
SELECT t.id FROM test t
WHERE t.user_id = $1
ORDER BY t.score DESC LIMIT 1
$$;
SELECT high_score_for_user(u.id) FROM test_users u;
runs in 10
Robert Haas wrote:
> Just for kicks I tried this out and the behavior is as the OP
> describes: after a little poking around, it sees that the INSERT grabs
> a share-lock on the referenced row so that a concurrent update can't
> modify the referenced column.
>
> It's not really clear how to get ar
