Re: Design of a database table

On 07/30/2018 07:37 AM, hmidi slim wrote:
> I'm trying to design a database table. First of all there are two
> alternatives:
> 1-) Divide the table into two tables and make a join.
> 2-) Design a single table.
>
> 1rst alternative:
> Create table data_periods(
> id serial primary key not null,
> period daterange,
> project_id integer
> )
>
> create table data_periods_info(
> id serial primary key not null,
> data_periods_id integer,
> data_sub_periods daterange,
> stock1 integer,
> stock2 integer,
> CONSTRAINT data_periods_allotment_id_fkey FOREIGN KEY (data_periods_id)
>         REFERENCES data_periods (id) MATCH SIMPLE
>         ON UPDATE NO ACTION
>         ON DELETE NO ACTION
> )
>
> The table data_periods contains 1M rows and data_periods_info 5M rows.
> I added an index to the table data_periods_info for the column
> data_periods_id
> I execute this query:
> select
> data_periods.id <http://data_periods.id>,
> data_sub_periods,
> project_id,
> stock1,
> stock2
> from data_periods
> inner join data_periods_info on data_periods_info.data_periods_id =
> data_periods.id <http://data_periods.id>
> where data_periods.period && '[2018-07-28, 2018-08-02]'::daterange
> and data_sub_periods  && '[2018-07-28, 2018-08-02]'::daterange
>
> I got an execution time of : 1s 300ms
>
>
> 2nd alternative:
> create table data_periods_second(
> id serial primary key not null,
> data_sub_periods daterange,
> project_id integer,
> stock1 integer,
> stock2 integer)
>
> I run this query;
> select * from data_periods_second
> where data_sub_periods && '[2018-07-28, 2018-08-02]'::daterange
>
> I got such a execution time : 1s
>
>
> Is it normal to get an execution time when using join relation greatest
> than the execution time of a table contains million of rows and many
> columns?

Not surprising given that you are searching for a date range in two
tables in the join versus only one in the other case. That fact that you
are using the same range end points for period in data_periods and
data_sub_periods in data_periods_info, to me, points to a design flaw.
If period and data_sub_periods are the same why separate and repeat
them? Also when asking for input on query planning/outcomes running
EXPLAIN ANALYZE on the queries and posting the results here will help
arrive at answer.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com