Postgres Professional
   

Re: Transparent table partitioning in future version of PG?

From: Tom Lane
Subject: Re: Transparent table partitioning in future version of PG?
Date: ,
Msg-id: 14898.1241816610@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Transparent table partitioning in future version of PG?  (Robert Haas)
List: pgsql-performance

Tree view

Transparent table partitioning in future version of PG?  (henk de wit, )
 Re: Transparent table partitioning in future version of PG?  (Robert Haas, )
  Re: Transparent table partitioning in future version of PG?  (Simon Riggs, )
   Re: Transparent table partitioning in future version of PG?  (Tom Lane, )
    Re: Transparent table partitioning in future version of PG?  (Simon Riggs, )
     Re: Transparent table partitioning in future version of PG?  (Alvaro Herrera, )
     Re: Transparent table partitioning in future version of PG?  (Robert Haas, )
      Re: Transparent table partitioning in future version of PG?  (, )
       Re: Transparent table partitioning in future version of PG?  (Robert Haas, )
        Re: Transparent table partitioning in future version of PG?  (, )
         Re: Transparent table partitioning in future version of PG?  (Scott Carey, )
         Re: Transparent table partitioning in future version of PG?  (Robert Haas, )
          Re: Transparent table partitioning in future version of PG?  (Tom Lane, )
        Re: Transparent table partitioning in future version of PG?  (Craig Ringer, )
       Re: Transparent table partitioning in future version of PG?  (Scott Carey, )
 Re: Transparent table partitioning in future version of PG?  (Scott Carey, )
 Re: Transparent table partitioning in future version of PG?  (Tom Lane, )
  Re: Transparent table partitioning in future version of PG?  (Craig Ringer, )
   Re: Transparent table partitioning in future version of PG?  (Simon Riggs, )
    Re: Transparent table partitioning in future version of PG?  (Scott Carey, ) 
Robert Haas <> writes:
>> so I think that it is much easier for the database engine to efficiantly
>> search two 500G tables instead of one 1T table.

> And that leads me to the opposite conclusion on this point.

I don't think there would be any difference on that score, either.

            regards, tom lane

pgsql-performance by date:

Previous:
From: Tom Lane
Date:
Subject: Re: Bad Plan for Questionnaire-Type Query
Next:
From: Laurent Wandrebeck
Date:
Subject: Re: Slow select performance despite seemingly reasonable query plan