Thread

1. AW: [HACKERS] create index updates nrows statistics

   Zeugswetter Andreas <andreas.zeugswetter@telecom.at> — 1999-05-26T07:28:07Z

   > > a create index updates the statistics in pg_class,
   > > this leads to substantial performance degradation compared to
   > > 6.4.2.
   > 
   > Create index did that in 6.4.2 as well --- how could it be making
   > performance worse?
   > 
   I am not sure why, but in 6.4.2 a create table, create index, insert,
   select * from tab where indexedcol=5 did actually use the index path,
   even if table reltuples and relpages was 0.
   It currently uses a seq scan, which is exactly what we wanted to avoid 
   in the newly created table case, but do want on an actually small table.
   
   Please apply the patch I previously sent.
   
   Andreas
   
   

2. Re: AW: [HACKERS] create index updates nrows statistics

   Jan Wieck <jwieck@debis.com> — 1999-05-26T07:43:29Z

   >
   > > > a create index updates the statistics in pg_class,
   > > > this leads to substantial performance degradation compared to
   > > > 6.4.2.
   > >
   > > Create index did that in 6.4.2 as well --- how could it be making
   > > performance worse?
   > >
   > I am not sure why, but in 6.4.2 a create table, create index, insert,
   > select * from tab where indexedcol=5 did actually use the index path,
   > even if table reltuples and relpages was 0.
   > It currently uses a seq scan, which is exactly what we wanted to avoid
   > in the newly created table case, but do want on an actually small table.
   >
   > Please apply the patch I previously sent.
   
       From memory not verified:
   
       Doesn't CREATE INDEX update pg_statistics? I think it does so
       the faked statistics only cause different joins to happen  as
       long  as  there  is no index created immediately after CREATE
       TABLE (HASHJOIN vs. NESTLOOP).
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #======================================== jwieck@debis.com (Jan Wieck) #