Learned Java from the inside while developing JVM & JDK for years. Then joined the world of distributed systems and databases, where remained ever since.
With the index and without table partitioning you scan entire data set - all the pizza orders that are being baked, ordered, delivered, etc. With partitioning you can scan a subset (only delivered pizzas or those that are in progress). You can add an index to partitioned tables as well, thus boosting the search further.
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.
With the index and without table partitioning you scan entire data set - all the pizza orders that are being baked, ordered, delivered, etc. With partitioning you can scan a subset (only delivered pizzas or those that are in progress). You can add an index to partitioned tables as well, thus boosting the search further.
Check the second article for more usage scenarious of the table partitioning:
dev.to/yugabyte/managing-data-plac...
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.