Sunday, December 5, 2010, 12:19:29 AM you wrote:
> Hmmm, what happens if I need 10 years of data, in monthly partitions? It
> would be 120 partitions. Can you please elaborate on that limitation?
> Any plans on lifting that restriction?
I'm running a partitioning scheme using 256 tables with a
Tom Lane wrote:
Partitioning using these techniques will work well with up to
perhaps a hundred partitions; don't try to use many thousands of
partitions.
regards, tom lane
Hmmm, what happens if I need 10 years of data, in monthly partitions? It
wou
John Papandriopoulos writes:
> I set up my schema using a machine generated SQL file [1] that simply
> creates a table
>create table ptest ( id integer );
> and N = 0..4095 inherited children
>create table ptest_N (
> check ( (id >= N_min) and (id <= N_max) )
>) inherits (ptest)
Tom Lane wrote:
Hmm. Rules? Triggers? You seem to be assuming the problem is at the
planner stage but I'm not sure you've proven that.
regards, tom lane
Hmmm, I vaguely recollect a similar thread, started by me, although with
fewer partitions. In my experience, pl
On 12/4/10 8:42 AM, Tom Lane wrote:
John Papandriopoulos writes:
I've recreated the same example with just one parent table, and 4096 child
tables.
SELECT query planning is lightning fast as before; DELETE and UPDATE cause my
machine to swap.
What's different about DELETE and UPDATE he
Ok, I caught one : an update that is stuck in waiting.
the first one blocks the second one.
ns |5902 | nssql | UPDATE "fastadder_fastadderstatus" SET "built"
= false WHERE "fastadder_fastadderstatus"."service_id" = 1
Am Samstag 04 Dezember 2010 schrieb Tom Lane:
> "Kevin Grittner" writes:
...
> > One option would be to create a different user for running queries
> > which read from complex views such as this.
>
> If you don't want to change the collapse limits, the only other
> option is to restructure this s
Am Samstag 04 Dezember 2010 schrieb Kevin Grittner:
> One option would be to create a different user for running queries
> which read from complex views such as this.
>
> postgres=# create user bob;
> CREATE ROLE
> postgres=# alter user bob set from_collapse_limit = 40;
> ALTER ROLE
> postgres=# a
"Kevin Grittner" writes:
> Markus Schulz 11/24/10 1:02 PM >>>
>> if i set "from_collapse_limit" (to merge the views) and
>> join_collapse_limit (to explode the explicit joins) high enough
>> (approx 32), all is fine (good performance). But other queries are
>> really slow in our environment (ther
John Papandriopoulos writes:
> I've recreated the same example with just one parent table, and 4096 child
> tables.
> SELECT query planning is lightning fast as before; DELETE and UPDATE cause my
> machine to swap.
> What's different about DELETE and UPDATE here?
Hmm. Rules? Triggers? You
2010/12/4 Mathieu De Zutter
>
> For each page load I first create an entry in that table, e.g.:
>
> INSERT INTO log_event (user_id, ip, action_id, object1_id, object2_id,
> event_timestamp, comments) VALUES (1, '127.0.0.1', 96, null, null,
> NOW(), 'TEST');
>
> After that, I want to retrieve the
Markus Schulz 11/24/10 1:02 PM >>>
> if i set "from_collapse_limit" (to merge the views) and
> join_collapse_limit (to explode the explicit joins) high enough
> (approx 32), all is fine (good performance). But other queries are
> really slow in our environment (therefore it's no option to raise
On Sat, Dec 4, 2010 at 1:35 PM, Marti Raudsepp wrote:
> On Sat, Dec 4, 2010 at 13:56, Mathieu De Zutter wrote:
>> I have no idea why in some cases the index scan is not considered.
>> Does anyone have an idea?
>
> I guess that it's because the currval() function is volatile -- its
> value has to
On Sat, Dec 4, 2010 at 13:56, Mathieu De Zutter wrote:
> I have no idea why in some cases the index scan is not considered.
> Does anyone have an idea?
I guess that it's because the currval() function is volatile -- its
value has to be tested for again each row.
Try this instead:
SELECT user_id
Hi all,
I have a table that stores all the page loads in my web application:
shs-dev=# \d log_event
Table "public.log_event"
Column | Type |
Modifiers
-+--+-
Am Freitag, 3. Dezember 2010 schrieb Kevin Grittner:
> Markus Schulz wrote:
> > i have a big performance problem
> >
> > [joining two complex views for reporting]
>
> What version of PostgreSQL is this? How is PostgreSQL configured?
> (The postgresql.conf file with all comments removed is good.
On 12/3/10 10:20 PM, Tom Lane wrote:
> John Papandriopoulos writes:
>> I've found that a k-ary table inheritance tree works quite well to
>> reduce the O(n) CHECK constraint overhead [1] in the query planner
>> when enabling partition constraint exclusion.
>
> Um ... you mean you're creating inte
17 matches
Mail list logo
