I am newbie with database using postgres since a year now, correct ne if I am wrong but does setting and index make me able to avoid full table scan and make the search way more fast (using btree or similar) then without having it ? Not quite following you when you say that I would still run a full table scan using and index. Btw very interesting, going for part 2 ;)
Learned Java from the inside while developing JVM & JDK for years. Then joined the world of distributed systems and databases, where remained ever since.
Yeap, you’re right, I confused you. Meant to say that with a single table you index the whole data set and do search with that index.
With table partitioning, you also can define indexes for individual partitions (partitioned tables). Thus, when you run a query two optimizations can kick in - first the partition pruning removes unnecessary partitions/tables and then you do an index search for the remaining partition/table.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am newbie with database using postgres since a year now, correct ne if I am wrong but does setting and index make me able to avoid full table scan and make the search way more fast (using btree or similar) then without having it ? Not quite following you when you say that I would still run a full table scan using and index. Btw very interesting, going for part 2 ;)
Yeap, you’re right, I confused you. Meant to say that with a single table you index the whole data set and do search with that index.
With table partitioning, you also can define indexes for individual partitions (partitioned tables). Thus, when you run a query two optimizations can kick in - first the partition pruning removes unnecessary partitions/tables and then you do an index search for the remaining partition/table.