Hi, how's the mic? Good. OK, I'll probably move, and then it'll probably be bad. So just say something if I get quite all of a sudden. That doesn't usually happen, though. So I'm Robert Haas. I work at Enterprise DB, which is a lot more yellow and a lot less blue than that slide. It's actually really supposed to be orange and black, but it isn't. And at Enterprise DB, I am the chief database architect. And in the community, I am a PostgreSQL major contributor and committer. And I'm here today to talk to you about next generation parallel query. As many people here probably know, 9.6 was the first release of PostgreSQL, which had any kind of parallel query feature that was user exposed. And in 10, we have quite a few enhancements. And I'm going to talk about both some successes and some failures today. I think in some ways, I'm very happy about what's coming in PostgreSQL 10, because I think we've really made a lot of very significant enhancements over what was present in 9.6. In other ways, I'm sad, because six months ago, I thought that we had solved a large fraction of the problems that there were. And now I know that that was totally not true. And there are many more problems that are still left to be solved, which is a little disappointing, because I like to be done with a project eventually. But on the plus side, if there's still more work to do, maybe they'll keep paying me. So I'm going to talk about parallel scans a bit, then parallel joins, then parallel aggregate. And in each of those categories, I'm going to talk a little bit about what has been done and what remains to be done. I'm going to talk about a few miscellaneous improvements that have been made in this release. I'm going to discuss some TPC-H results, and I'm going to talk a bit about future work. And feel free to pipe in with a question. As long as we don't get tight on time, I have 25 slides, and we have 50 minutes. So if I'm going faster than two minutes a slide, then there's probably a little bit of buffer in the schedule. And if we run out of buffer, I'll let you know. So when you think about accessing data via SQL, the most basic thing that you can do is just access data from a single table. You scan the table in some way. And PostgreSQL has a bunch of different ways to do that. Obviously, the simplest method is a sequential scan, which we abbreviate to SEQ scan, sex scan. And then you could also maybe want to not do that. So you can also access data in a table via an index scan or via an index-only scan or via a bitmap heap scan. So an index scan means that we go to the index and we say, give us the first tuple that matches the index conditions. And then when we get it, we say, give us the next tuple that matches the index conditions. Next one, next one, next one, next one, until there are no more. An index-only scan is the same thing except we attempt to avoid accessing the heap because we think that all of the data that we need is going to be present in the index tuple. And so there won't be any need to touch the table data itself. A bitmap heap scan is one of my favorite kinds of scans based on my previous experience as a PostgreSQL user rather than a PostgreSQL developer. Basically, what we do is we do a bitmap index scan, which means we zip through the index and find all of the heap blocks that we need to touch. And then we zip through the heap in order so that we hopefully get mostly a sequential IO pattern. And we look at each one of the tuples that the index pointed us to. So it essentially sorts the IO against the table, which is important when your tables are big and the index is accessing a lot of rows. And then we can also combine data with multiple indexes using bitmap and bitmap war operators. The importance of table scans from the point of view of parallel query is that the table scan, one table scan somewhere in the query, the driving table has to be scanned using a special kind of scan that is parallel aware. And that special scan essentially partitions the data. So wherever the parallel scan is, that is going, there's gonna be several workers running and each one of the workers is gonna get a subset of the rows from that table. And together they're gonna get all the rows from that table that match your search criteria. And so if a particular kind of scan is not parallel aware, then it cannot be the driving scan for a parallel query, which is sad. So how are we doing? Well, parallel sex scan is the first thing that we did because it was the easiest and that's fully supported from 9.6. And in 10, we have several enhancements coming which I think are very good. We now support Btree index and index only scans on Btree indexes as the driving scan in a query. And we also support bitmap heap scan in parallel but not bitmap index scan. So what happens is if a bitmap heap scan is chosen as the driving scan for your query, then the index scan will be performed by one process which will build the bitmap and then all of the processes can cooperate and jointly iterate through the bitmap visiting the heap blocks. So this is great if the index scan is short and the heap scan is really long but it's not so great if the index scan is a large percentage of the time that that access is going to take. The nice thing about this bitmap heap scan thing is because we're not relying on any parallel support in the index access method, we're able to do this for any index access method. It doesn't care whether it's Btree or Brinn or anything like that. And Brinn would be a very good candidate for this because the index scan portion for a Brinn index should be very, very small because Brinn indexes are tiny. Eventually, obviously it'd be nice to combine these things. So we could have the index scan also be parallel. That unfortunately requires specific work to be done for each index access method. We did Btree for this release. That's obviously by far the most important one because there are more Btree indexes out there than anything else. But it would be nice if someone wanted to do the work to extend this to GIST and JIN and SPGIST and all the other access methods that we have out there. Questions on table scans? Okay, so next up is joins. So there are three join algorithms available. We've got nested loop, hash join and merge join. And nested loops kind of come in two flavors. So the normal thing when you get a nested loop is what's called a parameterized nested loop, which means that one side of the nested loop isn't really scanning all of the data. It's something like an index scan driven by a value from the other side. So you're joining two tables, you're scanning along for one table sequentially. Each row you find, you pull one column value out of there and you feed that to the index scan on the other side of the nested loop and you go look up that value and see if you find any matches. That's a parameterized nested loop because the value that goes from the one side to the other side is a parameter. You could also have an unparameterized loop and one of my colleagues when they saw a draft of these slides said, what's an unparameterized nested loop? Right, well they don't happen that often but the way that they happen is if you say something like you select from two tables but your join condition is something really strange like this column mod that column from the other table equals zero, right? Then you've actually got a scan for every row on one side you've actually got to scan all of the data on the other side and check which rows match. People tend not to write these conditions very often because either slow and be there not that useful necessarily, but they do exist. So how are we doing on joints? Well, so first a little bit of general philosophy here. It's easy to perform a join in parallel and I put in paralleling quotes here for a reason by giving each one of the worker some of the rows from one side of the join and all of the rows from the other side of the join, right? So if I need to find all of the rows where a.x equals b.y, I've got all of b over here and part of a over here and for my part of a I do the join. I check for matches on the other side but I can't partition both sides, right? Unless I've got some trick because if I only see a subset of the rows from this side and a subset of the rows from this side then the match things might not match up. I'll miss answers to the join. So we can do a kind of, you know, version one parallel join by doing this. There's some problems with this which will become apparent in the following slides. So going through the join types one by one parallel nested loops are supported in 9.6 and also in 10. Parameterized nested loops actually work very well with parallelism, right? If you have an index scan that's being driven by a value from another table and you do that in parallel, it's fine. I get my values and I look them up and you get your values from some other rows and you look those up and everybody's happy and things are great. Unparameterized nested loops are also supported but of course they're pretty inefficient whatever data is on the outer side every worker's gotta scan it repeatedly. If it's not just a plain table but some kind of intermediate result set that's expensive to build every worker has to build its own copy of that intermediate result set which is not so hot. That's probably not a huge problem in practice because when I say unparameterized nested loops everybody says, huh? Which means you probably don't have very many of these and if they're not, if they don't work great it's maybe not the end of the world. Obviously it'd be nice to do better. So hash joins. We've got these in 9.6 and they'll still be there in 10. Each worker builds a separate copy of the hash table which is not great, right? If the table that were hashing is small it's fine, right? You got 10 rows or 100 rows or even 1,000 rows and you load them into a hash table and then you scan a subset of the other side of the join and you do a probe for each row and everything's great. If you've got a million rows and you need to put that into a hash table suddenly things are not so great, right? You're doing a lot of work. Every worker is doing that work repeatedly to construct their own copy of the hash table and it can easily get worse because it may be that you're building a hash table not on rows read out of a base table but that you're hashing the result of some aggregate which scans a terabyte of data and then aggregates that and then the result of that is what's going into the hash table and the planner is probably not gonna pick that plan because it would be very awful but you'd clearly like to do better. You really don't want everybody to be building their own copy of the hash table because what it effectively means is only one side of the join is parallel. On one side we partition the data but on the other side everybody is doing all of the work over again. So we have a proposed patch series to fix this. It does not look like it's going to make the cut for version 10 unfortunately because there are still some issues remaining that need to get fixed. Obviously that's a little disappointing because this would have been really nice to have but I think that one's probably gonna have to wait for 11. And then so the last kind is merge joined. In version 9.6 we just never did merge joins in the parallel portion of a query. In version 10 we do allow them but they've got the same problem as the hash joins and the unparameterized nested loops which is that every worker is building one side of the join in its entirety and joining that against the subset of the other side. And that's not great, right? So we don't have patches for this yet. We need some kind of a solution to this problem of how to do merge joins in parallel that is better than what we've got. And if you think about it a little bit it's actually kind of a tricky problem because a shared hash table is a pretty obvious solution to the problem of how to do a hash join in parallel, how to do a merge join in parallel is not as obvious, right? It feels like it's sort of an inherently serial algorithm. You've got two sets of values and you're trying to go through and line them up, right? Well, I mean, it doesn't work unless you've got one set of pointers that you're trying to line up as you move through the data. So what are you gonna do there? We have some ideas, we do not have code. So one idea is we do have code for partition wise join and parallel append. Again, this is probably not something that's gonna end up in 10 although the patches are written but they do have some issues left. So here the idea would be that you manually can partition your data. This is not something the system would, this first idea is not something the system would do for you but you would partition your data and then you would join between two tables that had a compatible partitioning scheme. And with those patches, the planner would be and the executor would be smart enough to break down your one big merge join into a bunch of smaller joins, one per partition. And of course, even if you can't parallelize each one of those, you can do multiple ones at the same time, right? If I've got my table divided into 40 partitions, I've got, instead of doing one big merge join of all the data in one table against all the data in the other table, if I'm joining on the partitioning key, I can instead do 40 little joins. This partition to this partition, this partition to this partition, this partition to this partition. So that's our first approach to this problem and we do have patches which will support that that are not quite ready to go into 10 unfortunately. So that's okay but it requires some explicit user action, right? You have to partition your data and depending on what the situation is, it might not be easy to find a partitioning scheme that's good for this and also good for other things that you wanna do. Yeah, right. So the currently proposed patch would require the partitioning schemes to match exactly what you're talking about is I think one of the things that we need to think about either as a revision of what that patch does or as a future step or something, right? Because that clearly is an issue. I mean, part of the problem is you don't wanna spend a lot of time pursuing planner optimizations that are not likely to work out well at execution time. You don't wanna spend a lot of time planning a query and then you've wasted more time than it was worth at execution time. But on the other hand, I think that's a real thing that you're talking about and you don't wanna miss those optimization opportunities either so that's a research area. Yeah, so beginning in PostgreSQL 10, we're going to have declarative partitioning where you can actually say create table partition by range or partition by list and then you can say create table blah partition of blah for values from blah to blah. So in previous releases, we didn't have that obviously and you had to sort of do partitioning in an ad hoc way using constraint exclusion and table inheritance and all of that fun stuff but that process is getting considerably streamlined in 10 which is what makes this kind of optimization possible. Okay, so if you can't or don't want to partition your data in a way that makes your merge joins fast, then you'd like something that lets the system do it for you. So a second idea is we could break up the merge join into a bunch of smaller merge joins using hashing. So we hash every row on both sides, right? And we take the low, let's say four bytes, four bits of the hash code and that puts every row that we're interested in into one of 16 bins. And then we do the same thing with the relation on the other side and now we've once again broken up one big hash join into a bunch of, or one big merge join into a bunch of smaller merge joins. It's an idea. Another idea that we're thinking about is a sort of parallel materialize node where on one side of the merge join the data is already partitioned. On the other side of the merge join you insert this parallel materialize node and under it there's some partial plan where each worker will generate some of the rows that need to be seen on that side and they go into some kind of a tuple store that everybody can read from. So then everybody still has to read through all of those rows, but the parallel materialize node means that all the workers can at least cooperate in generating those rows. So that would help when one side of the merge join is something like another join. You do that join in parallel, the output of that join feeds into this parallel materialize node which then allows the merge join to work correctly against some other parallel thing. That could be further optimized with something called a skip scan. So right now the way, imagine you're doing a merge join and you have an index scan on both sides, right? So index scan on one side, index scan on the other side. So what we basically do right now is we see these two index scans and whichever side is less, currently less, we pull another tuple from that, right? Which makes sense, right? This one's less, this one's less, this one's less. Now this one's less, this one's less. We keep pulling a tuple from the side where the value is lower and matching up equal values as we go. However, that doesn't work well if one side skips way ahead, right? So like imagine on one side we have the numbers one to a million and on the other side, we have the numbers 1,000, 2,000, 3,000, 4,000, 5,000, 6,000 and so on. So what happens today in Postgres's merge join and this is true with or without parallelism. This isn't specifically a problem for parallel query is we read one on one side and 1,000 on the other side. And then we look at the guy who gave us one and we say your value is smaller, give us the next one. And he says, two, give us the next one. Three, give us the next one. Four, give us the next one. Five, and we just keep doing that, right? And eventually we get up to 1,000 and then we're like, oh yay, a match and we emit the match. And then we do this again, right? It would be much nicer to say, to tell this guy who just gave us three or just gave us one, say to him, hey, I don't really care about anything less than 1,000. Could you just fast forward to 1,000, right? So that would be a good optimization even for non-parallel merge joints. And I think for parallel merge joints, it might help even more or also help or something because we have this problem of wanting to make sure that we're not doing all of the, you know, we're not repeating work, right? And having every worker pulling every row from one side of the join is not as good as having it somehow jump forward to the next interesting part of the dataset. This is pretty vague and that's because I don't really know how we're gonna solve this problem yet but I've become convinced that it's an important problem to solve. Yeah, right. So if you knew how the values were distributed, you could try to chunk up the two sides into ranges and then perform submerged joins on the ranges. The question is, there's some fuzzy details about how exactly you do that and doing it based on statistics is one of those things that might work out for you but it might also go badly wrong because we only know what the statistics are for the base table. By the time that table has been filtered and maybe joined and aggregated and so on, you may have statistics that aren't very representative. So you have to be careful not to over commit to a design that assumes the stats are accurate. Well, there is some overhead that's intrinsic to parallel query. So if you only have one worker that's really doing any work then you're behind in some sense. Also like, I think people will sort of be unhappy with that on a metaphysical level, right? Like you don't wanna see two or three or four workers start up and then have all of them except one just kind of sit there and not do anything. People are gonna report that as a bug. And I don't blame them, yeah. Exactly, right, yeah. So for index, for skip scans, going up a level from the bottom, if you're doing a skip scan and the thing you're trying to skip through is a B-tree index, as Peter is pointing out, there's a very natural way of doing that. Okay, so aggregates in PostgresQL. We've got three kinds of aggregates. So, and these are the names that are used in the query plan so they must be perfect. If there's only a single group that's being produced, we just call that an aggregate. That's like if you do select count star from table, right? There's one group that's coming out. Many times you have multiple groups and then you have to pick between a hash aggregate and a group aggregate. So when a hash aggregate, we just throw all the data into a hash table and we accumulate the transition state for each group within one hash table entry and then at the end, we have a complete hash table with all the data in it that we need and we dump out the results. The other option is to do a group aggregate where we sort by the grouping key. And then we have all the values in a particular group next to each other and we just aggregate one group, aggregate the next group, aggregate the next group and so on. So that's generally what the strategies for aggregation are. Now, how does that play with parallel query? Well, the way we're able to do this today is like this. We do what we call a partial aggregate which can be done using either, using any of those three strategies.  And it reads from a parallel, a partial plan. So each worker is running its own separate partial aggregate and it builds its own separate set of groups. And then those groups are fed up to the leader through the gather node which then performs a finalized aggregate step to basically if more than one worker created a group for the same value, you have to merge those groups before you get your final answer. How well does this work? No hands? Well, it works pretty great if the number of groups is small because you don't have to do very much IPC. If the number of groups is large, it's not great because if you're getting lots and lots of duplicates that then have to be merged, it's not fantastic. It often still wins. It's often still significantly faster than not doing parallel aggregation but you don't get the kind of speed up. One of the things people used to complain about in PostgreSQL was still a count star from table is really slow. It got noticeably faster when we got index only scans because it turns out in some cases, scanning the narrowest index to count all the tuples is a fairly fast way of counting the tuples in the table. And it got a lot faster still when we got this because you just do a sequential scan at the table and you've got four workers or whatever and each one chunks through as fast as it can counting them up and then you've got four subtotals and you total them up. So it's great for that kind of a case. When you got a million groups, less great. Still usually faster but not as much faster as we'd like. But the thing that really stinks about this is when the aggregate is not at the top of the plan, you see what happens here.  Now I need to do a hash joint but I cannot parallelize the hash joint because I'm already above the gather, right? The portion of the plan that runs in the workers is the portion that's below the gather node. And here I have to use up my gather node to get the aggregate done. And now I'm out of parallel mode because the leader has to perform the finalized aggregate state and that means this hash joint is, it cannot be done in parallel. Now it could be that under the hash, there's a second gather node and that that hash table is actually being built in parallel but that's parallelizing the build of the data that's going to go into the hash table. That's not parallelizing the hash joint itself. This is one of these problems that when I initially saw the design of parallel aggregate that David Rowley put together I was like, yeah, sounds good, great design. And then it took a while to understand that this was actually not good if you have this kind of a plan. I mean, the good news is many times your aggregates are actually at the top level of the query and you're not really doing anything after that or it isn't that expensive but if you have this kind of case then things are not so great. What we've been thinking about is it would be nice if instead of separating the partial aggregate phase from the finalized aggregate phase it would be nice if you had just a parallel aggregate that did the whole aggregate but somehow everybody talked to each other so that you didn't get wrong answers. It's pretty easy to see how to make this work with a hash aggregate. You have all of the workers read a subset of the rows. Each worker puts the rows that it sees into a shared hash table and then everything just works, right? More or less, unless you ran out of memory then you have some problems. But it's pretty easy to see how to do an aggregate that is a hash aggregate entirely within one, you know, down under parallelism. You just need a shared hash table to do that. It is less clear how to make this work with a group aggregate. That's tricky. But this would be cool because then if we had that some kind of parallel aggregate node that could run as an intermediate step underneath the gather, then it would combine with the parallel shared hash thing that I talked about earlier and let you parallelize the heck out of everything. Yeah. I think it is very similar to the merge join problem. Maybe not identical, but it's in the same ballpark. Questions on this? Are you mean at-hoc partitioning on the fly? I don't have a plan for that. I might have a plan for that sometime, but I don't have a plan for that today. Okay. Fair enough. Any other questions on this? I know this is getting a little bit deep into the nitty gritty of how queries actually run, which may not be familiar to everybody. So I hope I'm not leaving too many people behind. That is not true even on 9.6. You can have parallelism on child tables. Yeah, you can get a plan where you have an append node with a parallel sequential scan per child underneath it. That does work. Okay. So we've got a few miscellaneous improvements that we did here in version 10. Gather merge, merges, you know, if each worker has a sorted stream of tuples and they're all sorted in the same way, gather merge will bring those back to the leader while preserving the sort order. And that combines very nicely with some of the other ordering related things that we now have like parallel B tree index scans and parallel merge joins. Uncorrelated subplans can now be executed in workers, but each worker repeats the work just as in the join case, but it's better than nothing. Access to parallel query from PLs has now been improved. So if you're using procedural languages to issue queries and you're wondering why those queries are not actually using parallel query, that's been improved significantly in version 10. And we now passed the query text down to the workers. So if you look at PG stat activity, the workers in beginning in 10 will actually tell you what query they are involved in running rather than saying, yeah, I'm a parallel worker for something. Okay, so I want to talk a little bit about some TPCH results here. These were run by my coworker Raffia. They were done at scale factor 20, which means 20 gigabytes of data. She did add some extra indexes. We ran these tests on a power server, which IBM provided to EnterpriseDB, thanks IBM. Some of the other details of the configuration are up there. This was done on a commit before. Andres's faster expression evaluation stuff went into the tree. This is from about March 9th. So the results are not distorted by the things that he's fitted up. This is mostly just parallel query related changes. So these are the queries out of the 21 queries on TPCH where the plan changed and there's a note about what we used. And I'm just gonna pause here for a sec. I have a few more slides to get through so I can pause here too long, but just give you a sec to drink that in and then I'll talk about what happened here. So from that chart, you can see that the biggest wins here by far came from parallel index scan. There are a number of queries in the TPCH query set that seem like they can't be sensibly executed in any way other than an index scan on the driving table. So when that can be done in parallel, then you get big speed ups. How much of a speed up you get depends on what else is in the query. So query six is basically nothing but an index scan. So that's why it gets like four times faster because you have four workers and it scales well enough up to that point and it gets about four times faster. Query 14 has an index scan on the inner side of a hash join. So the outer side of that, oh, I have inner and outer backwards there. So the index scan gets faster because now it can be parallelized but the hash join still everybody has to build their own copy of the hash table. So that does not improve but you still see two X performance improvement on that query. Query two only manages to use a parallel index scan for a small part of the complex query but that small part gets a lot faster. So you see a significant speed up there. The relaxation of sub plan related restrictions also helped a lot. That was query 16 allowing the uncorrelated sub plan to be part of the parallel portion of the query even with each worker re-executing it bought us like 25% on that query, which is not bad. Gather Merge got used a lot in those results. It didn't always help on queries three, four, five, seven and eight. It really made no difference at all. I think a lot of the variation that you saw in those queries is actually just random fluctuation from run to run rather than any actual performance change. Some got faster, some got slower. There were three queries where it helped significantly. On query two and query 18, if you hadn't had the Gather Merge, you probably wouldn't have been able to use the parallel index scan either because the parallel index scan needed to provide the data in a sorted order for a subsequent merger aggregation step that was depending on the data being ordered. On query 17, Gather Merge avoided an expensive sort. Query 10, it was pretty much a wash. Actually, the query 10 number, yeah, that probably should be saying, no, I don't think so. So query, that shouldn't say query 10, but I don't remember which query it is. One of the queries here, well, so 12 is the one where it behaved really badly. 10 behaved badly, but for a different reason. The regression on 10 is actually not Gather Merge's fault, and I want to get to why that actually did happen because it's sort of interesting here. Parallel Bitmap Heapscan did not work out very well on this benchmark. It was not treated kindly by this particular set of queries. On query 10, that gigantic regression that you saw happened because the parallel Bitmap Heapscan was slow, but the thing is that if we'd done a non-parallel Bitmap Heapscan there, that would have been slow too. The winning choice is actually to use a parallel sequential scan. So 9.6 gets it right because the only kind of parallel things it knows how to do is a parallel sequential scan so we cannot mess it up. There are two underlying issues here in terms of why it picks this plan. The planner thinks that the cost of a Bitmap Heapscan, whether parallel or not, does not depend on how much memory you have available, and that is false because we are building a Bitmap which is limited in size by work map. And if you don't have enough memory, then it does what's called lossifying the Bitmap, which means that the data stored at the Bitmap becomes less precise and it no longer remembers which tuples it needs to look at, but just which pages it needs to look at. It turns out that hurts a lot and the planner does not care. So if you give that query a lot more memory so that the Bitmap does not lossify, the most of the regression goes away. The remainder happens because you lose like three seconds if you fix that problem.  And so it matters what the cost of the index scan is estimated to be versus the cost of the Heapscan and the planner is just wrong about what the relative cost of those two operations is. So despite this, it might be possible to fix this one by tweaking the costing settings a little. I suspect it is, but obviously there's work to be done there. I think the biggest thing is we really need to fix the planner so that it knows that lossifying the Bitmap hurts a lot. Query four was the other one where parallel Bitmap Heapscan got picked up.  But for some reason the surrounding join doesn't get faster even though the scan that is driving it gets faster. I have not yet been able to figure out why that happens but you can see what's happening here. In example, in the 10 results or 10 develop results the parallel Bitmap Heapscan is 2.2 seconds but the nested loop join takes 11 seconds to finish. Now in the 9.6 plan it took 5.6 seconds to do the same thing that we now did in 2.2 seconds but not all of that time translated through. The nested loop semi-joint only gets slower by 0.7 seconds even though the thing inside of it slowed down by more than three seconds. I don't know why that is yet either. So one thing that I've learned and I'm running short on time now. So one thing that I've learned from all of these results is that Amdahl's Law is a big deal which will not maybe surprise anybody who understands Amdahl's Law better than I did when I started this project. Basically what we're seeing is that Parallel Query makes the things to which it applies reliably about four times faster. The problem is the things that it does not apply to. So the work here is making sure that we're able to drive down the parallelism into every single part of the query and leave no parts unparallelized. So I think that's gonna drive a lot of future development in this area. As I mentioned, obviously we need to try to fix the way that we do parallel joints so that we get parallelism on both sides of the joint and not just on one side. We need to allow parallel aggregate to happen without terminating parallelism at that point in the plan tree so that the higher parts of the plan tree are not excluded from the goodness of Parallel Query. We need to do more work on init plan and subplan type restrictions. There are several problems that remain there that limit the ability to use parallel query in queries that involve those constructs. And of course, the limitation I mentioned in regard to bitmap scans is very relevant here. We can parallelize the heap scan but we can't parallelize the index scan at the same time. We've got parallel index scan or parallel bitmap scan with the heap scan in parallel but the index are not. We need to obviously put those two things together so that we can have everything parallel at the same time.  I think a lot of those things are actually planner problems. One of the things that we have discovered this release cycle is that it really doesn't help you to implement a large number of new parallel operators if they don't get picked in the cases where they win. In addition to the cases that I already mentioned, we've noticed that the costing seems to be off for hash aggregate. So there are queries where a gather merge and a group aggregate would actually execute faster than a hash aggregate but the planner thinks the hash aggregate is faster and picks it anyway. We haven't really figured out why that happens but we know it does happen sometimes. Some of the estimations on the TPCH queries in particular are incredibly bad like off by many orders of magnitude and obviously that makes it a little hit or miss whether you get a good plan after that. And the way that we currently select the number of workers is kind of dumb which doesn't really matter when you're talking about trying to do parallel query with three or four workers. If you're off by a worker here or there, it's not generally a catastrophe. If we wanna move up and do a parallel query plan that involves 40 workers, I think this matters a lot more. If you launch one worker or two workers and it doesn't help that much, it's kinda okay maybe depending on what your situation is and how tight you are on resources. If you launch 40 workers when the correct number would have been three, that's more significant. So more work is needed there. So parallel query in 10 is substantially improved from 9.6 but as you can tell, I've discovered a lot more things that need to be done than what we were able to do. So stay tuned. And that's it. Questions? Thank you, thank you. Right, so the question is about using TPCDS. I definitely think we need to move in that direction. One of the obstacles that we're gonna face is that there are quite a number of TPCDS queries that don't even run on PostgreSQL or that run for longer than I will live. And so probably we need to fix some non-parallel problems around TPCDS before we start thinking about the parallel related problems on TPCDS. But I do agree that's an area that we gotta get to. I think we've really gotta get some of this basic joint and aggregate stuff settled down first before we dive more deeply into the complex things like CTEs and window functions and stuff like that. But I totally agree with the point. Yeah, so parallelism like all parts of the parallel query all parts of the PostgreSQL query planner is cost-based. Okay, go ahead, Peter. A little bit. I can show you some of the plans afterwards if you're curious. Keith. If it was for you to run, each of them needs three, but sometimes running super fast and sometimes it uses a lot of... Right, absolutely. So I think in many ways this question comes down to something that's gonna become a bigger and bigger issue as parallel query becomes better and better. If you're talking about a 2x difference in performance when you get parallel query, maybe it's okay if you don't always get that. I mean, it depends on the situation, obviously. When you're talking about, the bigger the difference gets between when you get a parallel... Even 2x is a big difference. Yeah. Yeah, I think better worker management is a whole different area to explore. I mean, here I was mostly talking about what can we do to make things faster, but being able to sort of make the kind of usability improvements that you're talking about is another area for exploration. Eventually, I would like to get to a point where you can actually have workers move around depending on the workload. So one guy starts up, he gets all the workers, then a second query starts up and half the workers go over there on the fly, but we're a long way from being able to do clever tricks like that right now. I gotta stop because I'm out of time, but if people wanna come to talk to me individually, that's cool.


Hello friends, welcome back to another episode here on the channel. I hope you're all doing great and for anyone new to the channel. As always, my name is Lee, also known as Osiris. In today's episode, we're continuing on with our VGC Series 10 content featuring another obscure, not used, very often, restricted Pokemon. And that is going to be Reshiram today. Reshiram, the dragon and fire type from the black and white series. Very interesting Pokemon. I think it's got a lot of potential. And I have to say that I did take a lot of inspiration for this particular build, the Reshiram part of the team from Phil from that's a plus one. I watched a stream of his from a while ago. He was playing Psychic Seed Reshiram. Now, I don't know if the spreads are probably a little bit different, but we are playing the Psychic Seed. It gives you a little bit of extra kind of stability, staying par and makes Reshiram difficult to deal with. Now, the rest of the team is completely different from his. We do have the Tapilele. Obviously, we need the terrain support there. We went for a scarf variant, but we've got Magic Room as well on the Tapilele. It gives us a way to shut down things like Xerneas. And that's been something that was used in previous formats where Tapilele and the Restricted were accessible. And then supporting cast, we've got a level one Ninetales. Don't worry, it will be leveled up to level 50. So Ninetales going to provide a nice combination with something like the Whimsicot as well. I did want a Chlorophyll Whimsicot in the team, but unfortunately, I just didn't have the hidden ability. Don't have the ability capsule or whatever it is to change the ability either to a hidden one. So we've went with the Prancer one, which I do feel like it still works in the team and gives us a little bit of an extra buff in certain areas. Whereas other places, the Chlorophyll one would kind of perform a little bit better, maybe, but, you know, taking advantage of the sun irregardless that the Prancer one is still going to be good. Got Amungus here just to give us a little bit of stability, speak redirection as well with the Rocky Helm. We've got Intimidate from the Crooked Algamus, the Dark Typing as well. So all in all, I feel like the team can perform very well. I guess a Reshiram is not a Pokemon that we see very often, but I think we're going to be able to pick up some results today. As always, the poker pace is down in the description below. I'll have a couple of games, show you how the team pilots and then we'll end up with the rental team at the end of the episode. So I hope you enjoyed today's episode. Let me know down in the comment section what your thoughts are on Reshiram as a restricted. Do you like it? Have you tried it? Tell me, tell me. I want it here. But without further ado, friends, we're going to jump straight into game one of today's episode. Okay. So first up today, we have Efra VGC playing a team of Groudon, Zaptos, Cherrim, Enti, Dustclops and Incinero. So again, we've got speed control on the team in the Dustclops. Maybe the Enti maybe has Bulldoze, but the Dustclops going to be the main kind of speed setter on the team supporting the Groudon. So trick room going to be the main mode for my opponent to kind of go down. We could go something like Reshiram. I feel like Reshiram is pretty good as a lead for sure. We could go Tapilele as well, to be honest, because it gives us real firepower to start with. It stops the fake up from the Incinero as well. My opponent doesn't really have terrain support. We probably want some sort of trick room kind of countermeasure, which would be good in a Moongus, although not great against his team overall, just with all the fire types and flying in there. Do we want Intimidate or do we want something like... I mean, a Moongus could be good if we don't bring the Lele because then, you know, if they set the trick room up, we can kind of on-call them into that. I feel like Ninetales could be alright as well, but Krukreda probably the better option out of everything because Kruk kind of can come in, can Intimidate, something like the Groudon, immune to stuff that the Zapdos is going to throw out to us. It's just going to be a little bit annoying. Hits the Dusklops for Super Effective Damage. Just needs to watch out for the Cheramite. I feel more than anything. So, let's see how this first one goes. Let's see how this first one goes. The Great Friend and Groudon. So, Anti-Groudon. Well, this isn't the worst. I feel like we played this team in our last episode, you know, and this is like Scarf Anti, which makes it a little bit more tricky to deal with, of course. We could protect Reshiram here and just get some damage onto the Groudon, or we could go after the Anti as well. Actually, that might not be a bad play, to be honest. So, I think, yeah, like, depending on what we've got in the back to kind of come in, we've got a way to hit the Anti for good damage. I mean, we've got a Moongus to come in. The Intimidate will help. I think we'd probably use Lele here. We could Magic Room as well. Get rid of items. Could be a play, but it feels like a little bit of a waste, to be honest. I think we just protect Reshiram. Just go for the SciShock into the Anti. Hope that we can outspeed the Anti. If it is the Scarf variant, of course, it might not be. Yeah, it's going to go straight after the Lele here, and that is us down. Okay, well, they're locked into Sacred Fire, right? They are locked into Sacred Fire. So, they can only precipice blades us. Reshiram definitely outspeed in that Groudon, and we can bring in Crocodile. Look at that, I'm not... Do we bring... Yeah, I think we have to. We have to Intimidate the Groudon. I mean, a Blue Flesh should get the Groudon, in all honesty. Like, it really should get the Groudon. Crocodile, are we going to be able to take down? I think we have to probably protect Crocodile here from a Sacred Fire, in all honesty. The other option is go Earth Power into the Anti, but I don't know if that'll be enough to take it down, but at the same time, we're going to have to take a Precipice Blades, which is going to, like, really hurt. Whereas a Blue Flesh should be enough to get the Groudon here, and if we protect... We've got to hope that we don't need to take a Precipice Blades, but I can't see them going Sacred Fire into Reshiram here. They've got to go off the Crocodile. Scarfed Anti, though. Yeah, it's the same team we played yesterday, I think, with the Mewtwo team. Groudon, I'm going to switch out. Okay, that's kind of fine, because, like, Charm coming in is just going to get absolutely obliterated here. It gives us a little more room, I guess, because we could potentially sacrifice Amungus the next turn to a Sacred Fire from the Anti. We'll get this Blue Flare off, which is... Yeah, I mean, takes the Charm down to its sash. I mean, this actually opens up the door for us a little bit more, where we can Earth Power into the Anti, because the Anti is a big thing that's given us a lot of issues right now, where we could switch into Amungus. Sack Amungus here, go for the Earth Power. Hope the Earth Power is enough to get the Anti. And then, like, what's the Charm really, really going to like? Is it threatening too much? I mean, the Anti has got the Special Defense Boost here, which does make it a little more tricky to deal with, of course. But at the end of the day, we can get Kukadar back in, we can then protect it, deal with the Anti. We should be able to get it in two hits. Sacred Fire can miss as well, although it's deciding not to today. So, Amungus is going to take that, not very well. So, we're kind of depleting, pollen puff. But, yeah, we're not really worried about that too much. The Earth Power, the pollen puff is a little bit awkward for us to deal with, but I mean, they're not going to be able to pollen puff off the damage of another Earth Power this next turn. So, that's a big thing. If they pollen puff their Anti, Anti does go down. And then, Kukadar will pressure them in a good spot to kind of potentially clean up the rest of the game. Depending on what they've got. So, Earth Power again, we have to protect. We have to protect.  I think the big problem for us would be if the Groudon comes in and then the Sun goes away and then we don't have that blue flare boost, which might make it a little bit more awkward for us to deal with. So, Zapdos coming in. That's a nice switch from my opponent, in all honesty. They're going to join, I think, Solar Blade. Yeah. What base speed is Charum as well? Like, because did it outspeed us? 85. It shouldn't outspeed Will, outspeed Reshiram. Kukadar, we are max speed Kukadar Jolly. So, we're 92 base speed. So, we should get the jump on Charum. So, we will be able to get Charum now and blue flare into the Zapdos. So, they're base 85. Let's just Darker Slariat into that slot just for safety, because we don't want to miss with like a Rock Slide or High Horse Power. Where the ball coming out. Not ideal for Kruk, but can take that. Darker Slariat there, and the blue flare should get rid of the Zapdos. The Sun disappears this turn as well, which is actually kind of alright for us to be able to get a blue flare into Groudon to potentially take it down. Because if it comes down to like Anti and Reshiram, then we're fine. So, the terrain disappearing. Groudon coming in, we'll get the Sun back up. We know, like, what's the Anti got though? Has it got something like, if it's got Bulldoze, that's terrible for us. If it's got Bulldoze, which it quite possibly has, you know? Like, Bulldoze, Precious Blades just wins the game for my opponent. We have to go blue flare, blue flare. And protect Krukadal. I mean, do we protect Krukadal? Probably not, you know? I think we probably go High Horse Power into Anti. Or do we protect, because then at least, if they go for the Sacred Fire, which it's likely they do, right? Then at least Precious Blades is still a double target attack, which makes it a little bit more likely that Reshiram could take it. But it depends on the build of the Groudon. Hopefully we see the Sacred Fire and not Bulldoze. Snarl, okay. Still not ideal. Could have done with that missing. But Krukadal not actually affected by this too much, so Kruk still might be able to do this, depending on the damage here. Yeah, might be able to... Oh, the burn. The burn! The burn! Okay, well that light locks it for us really. Because it's not really not going to be a problem anymore. Precious Blades will take that. Because of the burn, we get really lucky there. Although I think Krukadal then would have been able to close the game out. So, not like so, so lucky. Because now we can just Earth Power the Anti. We know it's locked in. Darker Slay it into the Groudon. That would be enough to get the Groudon here. So, like I still think that Krukadal would have been able to close that one up without the burn. We really just lost Reshiram there. But then you're locked into Snarl. Krukadal's going to have to beat Groudon. So we would have been able to take it down. So, off to a decent-ish start. A bit shaky, but we will move on to Game 2 of today's episode. Okay, up next we have an Ice Rider Calorax. Stack Attacker in DD Anti. A Lolan Executor and an Urshifu. So, the uprise of a Lolan Executor. We did play one last week on the channel and we didn't go down too well. So, hopefully we can get a better result here. Heavy Trick Room team, of course. You've got the Pokemon that are going to perform out of Trick Room pretty well. Are going to be things like Anti, Urshifu. But the main speed control on this team is going to be Trick Room. Running right through things like Ice Rider Calorax has access to it. Stack Attacker. I'm pretty sure a Lolan Executor does as well. Amunga is going to be quite useful here if the Trick Room does go up. So, we need to probably bring that. I think Kugudal for the Intimidate is pretty nice. Not so good against things like Anti, of course. Because it is going to outspeed us naturally. The Urshifu could be a little bit problematic as well. But we do have the Chopper Berry there, which can kind of help. Do we just go? Big Blitz Mode with something like... 90. I mean we could go. We could pull a little bit of a sh... And the Psychic Train makes it difficult to pull the Encore. Disable combination that we've got between Ninetales and Whimsicot. But Ninetales is quite nice because it does have the spread attack where we can actually just nail something. I think we go Reshiram. Ninetales. Tepilile. Amunga. Yes. We're locking them with that. See if it's going to be good enough? I don't know. I don't know. I don't know. The amount of firepower we have, we should be able to deal with the Ice Rider pretty well. But we'll see. We'll see. I don't know. Ninetales gives this Sun Boost to Reshiram, which is just insanely powerful with that Blue Flare. Like insanely powerful. And they're bringing the Psychic Terrain. So, you know, we've got the Heat Wave, which gets around the redirection, which is super nice, although they're going to be able to get trickered up here, which is not ideal to say the least. But the Ice Rider is not in the best of spots. I think we just double into the Ice Rider here with a Heat Wave. And I mean, could Disable follow me? But we're probably better off just going for a Heat Wave here, you know, in all honesty. Yeah, the thing that it had was Disable Onco with Whimsicot. And it felt quite a nice combination with the Ninetales where we could kind of utilize that. I'll go for the Blue Flare and the Heat Wave here. I think it's pretty overwhelming because they're going to go redirect, right? We do open the door for them to get something like Stack Attack around the field, you know, which isn't great because we'll remove, especially when there are weakness policy, which is not ideal. But we do have a Moongus coming if they're setting the trick on us, which they're likely to do here, right? Yeah. And the beauty about Moongus is it does underspeed the Ice Rider because it's not as slow as just a Glastria. Yeah, Stacks coming onto the field. A Moongus and Tapu Lele in the back. Not the Pokemon you really want. It's like do we just allow Ninetales to go down here and just try and Heat Wave and then just protect Reshiram? I think that's probably the best protocol here because then we can get a Moongus in and just put that Kallarex to sleep. We know it's not got safety goggles. The best that my opponent can do in that situation is going to be flinching us with a Rock Slide. That's the best haul. So, this boost is not ideal at all. But it is the defense boost.  The Glacier land's coming out. But our only option is a Moongus. So, we'll spore. Yeah, we'll spore into the Kallarex and we'll go after. We'll chase after the, we'll spore. And we'll blue flare into the Stack Attacker. And hope we don't get flinched. Hope we don't get flinched. They are a life orb as well. So, they're going to hit pretty hard. But Reshiram should be able to take at least one Rock Slide. They're going to try and double Rock Slide. I mean, a Moongus would be able to take a double Rock Slide here. Oh, a Moongus dodges, but Reshiram going to have to take one. Not ideal. But blue flare, as long as we get it off, we're going to be in a good spot. Yep, blue flare. This should be enough to take it down. And then, yeah, Moongus in a great spot. Depending on what comes in, of course. What's the next Pokemon going to be? Urshifu. So, that's actually pretty good for us. Pretty good, because we can just spore. And we've got Lele in the back. Okay, how many turns of trick room we've got? We can't really protect on the Urshifu. But we may underspeed the Urshifu. If it's max speed, we probably underspeed it. So, we could drop a Drake on it. What variant is it? Let's have a quick look. Is it the water? Yeah, water. Yeah, we'll drop a Draco. As Joey would like to say, let's drop a Draco. I should have my drop a Draco hoodie on. But we should underspeed the Urshifu here. I think we'll be pretty fine now. Maybe it would have been better going after the Kalarax, but they underspeed us. We're in modest Reshiram. They're going to get us. They're going to get us, even with the Sunup. Are they going to get us? They're going to get us. Yeah, just, I think, yeah. Very close. Oh, the Sunup. It doesn't do a whole lot of damage. Okay, well, we've got the type of Lele to come. We just need the Kalarax to stay asleep now. We really do. We'll just moonblast the Kalarax. And we can spore the Urshifu. Yeah, we don't want to lock in. We don't want to lock into side shock. Yeah. We just need the Kalarax to stay asleep. If it wakes up here, we're done. We are done for. But the trick room kind of helping us out a bit. And then when the trick room ends, is it this? Turn it ends. Okay, Urshifu just protecting here. That's fine. Come on. Plus one. We're done. Yeah. One-time wake-up. I mean, what can you do? What can you do in that situation? Turn wake-up. We did what we could. Good game to my opponent. Pretty salty about that. Pretty salty. I didn't expect the Urshifu to underspeed us in trick room. That's the thing. So it's a pretty slow Urshifu. If you'd had a little bit more health, maybe we could have. We could have got that. Drop the Draco. I think that would have been game. It's unlikely they would have been sashed. I would have thought from that point. So anyway, good game to my opponent. We'll hop over now, friends. And we'll get the rental code for today's tea. Okay, friends. Here is the rental code for today's team. If you do try it out as always, please let me know down in the comment section below what your thoughts are on Reshram in the build in general. And if you've had fun with it, that's the big thing. We didn't really get to see too much of the Whimsicott today. Like I say, it would have been nice to have the chlorophyll ability. So if you do adapt this team for yourself, maybe that's something that you look at. Because the chlorophyll doesn't then conflict with the psychic train that you're going to be pulling up with the Tapulele. A little bit unfortunate in that last game. I think really in hindsight, the Tapulele was probably not the best call to bring in that position. Maybe the crocodile might have been better. But then again, it wouldn't have really helped us out against the ocean food that Whimsicott in that situation would have been a lot more helpful in that situation, especially because we would have had access to something like Encore who could have really made use of rather than the Tapulele that was kind of locked in. And the wanton wake up, you were undoubtedly going to get punished from that, weren't we? So swings and roundabouts, isn't it? But have fun with the team. Like I say, if you do try it out, thank you so much for tuning in. Hope you've enjoyed today's episode and back tomorrow with another episode on a brand new team. So stay tuned for that, friends. Have a great rest of your day. And more importantly than anything else, take care of yourselves. And until next time, bye-bye.


In the world of shopping and retail, the e-commerce business has become a significant front runner. Pretty much anything that you need or want, you can find with a simple Google search and a few clicks and in a few days it'll be in your front door. Now, funny enough, as profitable and as huge as the industry is, it's actually one of the lower cost businesses that you're able to start up. Since we are in the dropshipping business, we don't have to worry about storing inventory or shipping anything. We have our suppliers to do that for us. We are pretty much the middlemen. So since we don't have to worry about the time-consuming and labor-intensive process of purchasing all of our items and shipping them, we can focus all our time and effort into finding the winning products that we're gonna be selling. Now, that in itself can be a fairly time-consuming process. You need to find out what's trending, what products are popular, and not everything sells all of the time. Now, you know that we here at AutoDS got your back and we're here to help you succeed. So in this video, we're gonna be talking about the 14 best niches for your dropshipping business.  It's pretty much just a specialized segment of a market, so it could be shoes and apparel or jewelry and watches, sports and fitness, things like that. It's really what you would call the entire category. So in itself, really, dropshipping is a niche and underneath that, there's a bunch of different niches. Now, having an entire catalog of similar or niched items actually has potential for huge profit because there's already demand in the market for these particular items. You just have to target that demographic. Before we get started, my name is Mario with AutoDS and if you like videos on the dropshipping niche, then make sure to hit that subscribe button so you don't miss out on any future content. Remember that we're here to help you grow and scale your business, so you don't wanna miss out. Make sure to hit that subscribe. Now, starting off our countdown in at number one, we have the health and beauty care business. This is a booming industry that is not slowing down. It's projected to hit over $600 billion by the end of 2023. Now, one of the awesome things about this particular niche is the fact that it's so big that there's a never-ending supply of products. The variations are endless. Now, that being said, a lot of these products also work together. So you have a huge potential to be able to upsell or sell things in bundles. And I'm talking about this from experience because let me tell you that when my wife purchases a makeup brush, she doesn't just buy one brush. She buys an entire set. So potential for upselling is there. Now, some of the more trending products in this market are facial beauty rollers, makeup brush sets, anti-snoring mouthpieces, neck massagers, hair clippers, lash lifting sets. There's a ton of different products. If you want a longer list of products to offer either in this niche or any of the other niches that I'm gonna list, make sure to check out the description down below. The link to the article will be there. Coming in at number two, we have men's fashion. The fashion industry is usually tailored towards women, which makes the men's fashion niche a lot less saturated and gives us a lot more potential for profit. Now, fashion is always gonna be in demand. The only thing about this niche is that you have to keep up with the trends.  Now, some of the best-selling products in this category are slim fit trousers, 3D printed all over shirts, which if you don't know what that is, it's pretty much just a T-shirt that's printed all over. The whole thing is printed. There's no blank spots on it. Cycling jersey sets, which I've actually seen a lot. A lot of the times when I'm out driving, I see somebody in their bicycle. They always have a full set on. They have the matching shirt and shorts. Another thing is corduroy shirts and cargo pants. Now, those two are actually my favorite. Also remember that a lot of these things have to do based around the seasons. So a lot of times you're not really gonna be selling sweatpants during the summer or shorts during the winter. So just keep that in mind for when you're listing your items. Up next on number three, we have women's fashion. Now, just like men's fashion, it never goes out of style. It's always gonna be in demand. Now, in the women's fashion industry, there's a lot. And I mean a lot of variation. Fashion is a personal expression of style, which means there's always something for everyone. And that makes this business extremely lucrative. Now, as I did say before, in the women's fashion industry, there is a lot of competition. So just make sure to keep up with the trends. Now, one of the more highly suggested products that I think you should add to your store are the legging and sports bra yoga sets. Those are extremely popular. You see those everywhere. Personally, living in South Florida, if I go to the mall, I'm gonna see at least 10 or 15 people wearing the same exact yoga set. So trust me when I say this is a very hot item and you want to have this in your store. Another thing to check out are the thin puffer jackets. These are extremely popular, especially during the winter and even more in the states that it snows. Furnishing our number four spot, we have furniture and home decor. Ever since the pandemic, more people than ever have been spending time at home. And that's mainly because they're also working from home. As a result of that, everyone wants to make their house or their little space that they're working in or wherever they're staying at. They want to spruce it up, make it a bit more personal, make it more them. Which in turn, the demand for furniture, home furnishings, home office equipment has skyrocketed. One of the really good things about this niche is the fact that you have high ticket items. High ticket items means you can sell them for a higher profit. Some of the more profitable products in this niche can include side tables, rugs, LED candles, artificial plants, the list goes on. And once again, if you want a more detailed list of products for any of these niches, check out the description below. The link to the article will be there. Now coming into our number five spot, we have jewelry and watches. Jewelry and watches go hand in hand with fashion and for one, they're never gonna go out of style. Absolutely, everyone loves a piece of jewelry. Everyone loves a watch. Any occasion that comes up, whether it's a birthday, Valentine's, Christmas, jewelry and watches are always gonna be an extremely popular gift. Another good thing about these items is that you have a ton of different variations, whether it be low ticket items or high ticket items. They can start off with maybe $10 or $15 and go up to the hundreds or thousands. Now, when it comes to jewelry and watches, you do wanna make sure that you target the right demographic of people. A lot of people have different budgets when it comes to these kinds of things, so you don't wanna be offering somebody that has a lower budget, a higher ticket item, or vice versa. One way to combat that is just have a bunch of different variations, have lower priced and higher priced items. A few of the items that you do wanna offer in your store though can include the ever popular golden chain. Everyone loves the golden chains. Silver ring sets, people love rings and when it comes to silver rings, they tend to be on the lower ticket side. You also have things like the heart and letter necklaces where you just have the little heart or somebody's initials on there.  The possibilities for this are endless and trust me, somebody's gonna like what you have to offer. Just have a bunch of different variations on there and you'll be good. Quick tip, always try to offer handmade jewelry. When it comes to handmade jewelry, people absolutely love it. They love the uniqueness of it and the fact that it was made by somebody by hand. People typically tend to spend a little bit more on custom and unique pieces of jewelry. Now, in at number six, we have office supplies. Office supplies are used all the time. Office supplies tend to have a lot of consumables like paper, ink, pens, which are always running out and always being replaced. There's also a very broad demographic of people when it comes to this niche because everyone has their preferences when it comes to type of paper, type of pens, brand of paper or maybe brand of folders that they use. There's a lot of things and a lot of times people tend to associate their brand or their business with a particular brand that they're using. So let's say in my business, I could use a particular set of pens just because I like how they write. Now, once again, the number of items that you can offer for this are endless, but some of the things that you wanna make sure that you have in your store are always gonna be electric pencil sharpeners, paper, staples, staple holders, notepads, desk organizers. There's a lot of different things that you can offer. Just make sure to offer a nice variety of them so that way you can have something for everyone. Now, coming to our number seven spot, we have home improvement tools. Ever since the pandemic, there's been a huge boom in the DIY industry.  Everyone wants to be able to do it themselves and be able to fix it themselves, which in turn can make it a more cost-effective option than selling office furniture because instead of selling the furniture, we're selling the tools to fix that furniture. Now, there's a lot of different items that you can offer in this niche. Some of them being things like mop and broom holders, like the ones that you can stick on the wall so that way you can put your broom on the wall to take up less space.  Now, remember that you also always have the possibility to upsell. You can offer a cordless drill to help you install that new door handle that you just bought. Now, in our eighth spot, we have consumer electronics. This is also something that, once again, is not going anywhere. Everyone needs to always replace either our charger or a USB, maybe they lost their mini SD card. There's a lot of things that you can offer in this niche and the demand is always gonna be there. Also, technology is always improving. It's always getting better. Storage sizes are always getting bigger while the products themselves are getting smaller and the average consumer is always gonna want the latest items. There's always gonna be new demand for products on this niche as well as new items that are gonna be coming out. Some of those items can include portable Bluetooth speakers. Whenever there's a pool party or whenever there's an outside gathering, there's always gonna be music and whenever there's music, people love wireless. That's where the Bluetooth speaker comes in. People also love selfie ring lights. The selfie craze is bigger than ever and so is vlogging. So when it comes to having the proper lighting, ring lights are a must. Another few products that you can offer are adjustable VR headsets, gaming headsets, portable chargers, storage drives. Again, the possibilities for this are endless. The number of items that there are at there are never ending. Next up, we have toys and baby products. Babies are being born every day. Kids are growing all the time and they're also letting go of their old toys and wanting new ones. Not to mention they're always breaking their old toys as well. Parents tend to focus a lot of time, energy and especially money on their kids. So they're always finding new ways to be able to try to entertain them. Also, parents always want what's best for their kids. So always try to offer products that are age-appropriate and safe and high quality. Now, some of the more popular items that you can offer in your store can include mobile rattles, the bubble lawn mowers, which kids absolutely love, glow-in-the-dark stickers, baby thermometers and the list goes on. Now, remember that when you are selling these items, especially for kids, you always wanna make sure that you sell high quality items and avoid the items that could potentially be dangerous for kids and have little pieces and things that they can swallow. Now, in our number 10 spot, we have fitness and gym equipment. The awesome thing about this is that you can target two different demographics. You can target the people that go to the gym itself and the people that work out at home. People are always trying to be healthier, eat better, work out more. So this niche in particular is something that's always gonna be in demand and there's always gonna be a market for these types of products. One thing to note is that when it comes to targeting these two different demographics that I mentioned, the people that work out from home and the people that work out at the gym, the people that work out at home tend to have a higher budget. They tend to purchase higher ticket items a bit more because they actually need to purchase the equipment to be able to do these workouts at home. They can be purchasing things like a treadmill or a dumbbell set or even a bench. Now the people that work out at the gym are gonna be purchasing items that are a bit different. They can be purchasing things like water jugs, bands, different types of workout, apparel, things like that. Now a few things that can target both demographics can be things like jump ropes, resistance bands, water jugs, yoga mats, muscle massagers and a few other things. Since people have been spending much more time at home, that has also increased the demand for outdoor products. So people have been wanting to step outside of their comfort zones, step outside of their house for a little bit to just escape the home office vibe and just have some fun outside. Which brings us to our number 11 spot, outdoor entertainment. Now this niche in particular is actually a bit tougher to get into. So one thing you really wanna focus on when starting this, if you decide to get into it is do a lot of research on your competition and see what's really trending out there and what's really selling. A lot of these products are used and abused.  So you always wanna make sure you work with a reputable supplier that has high quality items. Now there's a lot of things that you can offer for this particular niche, but a few things that you can include can be a table tennis set, a volleyball net that you can put in your backyard. And one that really calls my attention because it just sounds like a lot of fun is a backyard zip lining set. Another thing is you have a huge potential to be able to upsell. You can offer things like a tent along with a sleeping bag and maybe even add on a water jug or something like that. In our number 12 spot, we have pet supplies. These days, people absolutely love their pets. Sometimes they love them even more than they love their own family. It's crazy. People go crazy over their pets and they have no problem in spoiling them.  Whether it be a small lizard that fits in the palm of your hand or a huge dog that tries to act like a little puppy can sit on your lap, the different amount of pets that there are out there are endless, which makes the number of products that we can sell in our store endless as well. From a pet's habitat to their accessories and toys, the variety of products that we can sell are endless. And the best part is, a lot of the times people don't just have one pet. Sometimes they have multiple. Some of the more popular pet items that you can offer in your store can include things like car seat covers or even sofa covers for dogs and cats, pet crates, chew toys, beds. There's a lot of different things that you can offer. So make sure you have a good variety so you can cater to all the different types of pets out there. Securing the number 13 spot is home security. Unfortunately in the past few years, home security has become a very prevalent issue. Criminals are getting smarter, they're getting more sophisticated, and they're able to start figuring out new ways around certain security systems that we already have. Luckily, technology is always improving and so is home security. Having some of these items can help deter burglars or even record certain situations just in case. A few very popular items that you can offer are things like motion sensors, motion video cameras, night vision cameras, Wi-Fi security alarms. Just always make sure to consider the importance of home security and its growing necessity. Finally, in our number 14 spot, we have car accessories. People absolutely love their cars and they love putting their own personal touch to them so that way they can stand out. Now the best part is that there's just so much that you can do to a car that there's a lot of products that you can offer. You can offer products to spruce up the inside, the outside, make it sound better. There's a lot of things that you can do to a car. One thing that you can offer that is something that people absolutely love and at this point has become a necessity is a dash cam. They have a few different dash cams, some that we can record the front as well as the back. Another few things can be phone chargers, phone mounts, LED lights, and even a little garbage can that you can carry on your car to keep it clean. Now that we know the best products to offer in our drop shipping business, it's time to get to work. We have to start looking for the products that we wanna offer. We have to start looking for the suppliers and we probably wanna look for multiple suppliers. We have to start optimizing our titles, coming up with descriptions, taking pictures, downloading pictures from our suppliers' websites. There's a lot to do. Now, luckily, we can save the headache of having to do all of that labor-intensive and time-consuming stuff. There are a few tools that can really automate the entire thing and just get us up and running in no time. Using an automation software like AutoDS can really save a lot of time when it comes to setting up our stores. It can turn weeks of work into days or maybe even hours. For example, one of the processes that AutoDS can streamline for us would be the product importing process. Whether you have one or multiple products, AutoDS makes it super simple. For example, one of the processes that AutoDS can streamline for us is the product import process. If we look on over at our AutoDS dashboard and click on add products, we can see here that we have the option to upload either a single product or multiple products. Let's go ahead and click on single product and then from here, all you have to do is paste the URL. Another option that you have is go back to the added products and then hit multiple products. From here, you can enter multiple URLs or you can upload using a CSV file. Another thing that you can get with AutoDS is complete and total order fulfillment. AutoDS will fulfill the entire time-consuming process of ordering products and shipping them to your customer as well as providing them with the tracking. Now, if you wanna see the status of certain orders, that's super easy. All you have to do is go on your AutoDS dashboard then head on over to the products tab and there you can see the status of all the different orders that have come into your store. You can see that this one over here is pending. This one was already ordered from the supplier. This one was actually returned and these next ones have been shipped. Now, on this Nomad lamp, it actually shows that the return has failed. Let's see why. If we hover over the little exclamation mark, you'll see that, oh, it failed because the return window is closed. As you can see, the AutoDS order details page is actually very detailed. Now, let's check out their handy price and stock monitoring feature. For that, let's go over to the products tab and once we click on there, you can see exactly how many your supplier has on hand. You can also see the price of the item and how much you're gonna be making a profit. Now, the cool thing about this is that AutoDS will monitor price fluctuations as well as stock fluctuations. So, for example, if your supplier runs out of a certain product, they will automatically switch that stock to zero or sold out on your store. So, that way nobody makes the purchase and doesn't receive the item. And it can also avoid the customer from having to go through a cancellation process where you have to explain to them that you don't have the item or whatever the reason may be. Now, one very unique feature to AutoDS is the price optimization feature. What this does is depending on how well or how bad the product is selling, it'll adjust the price accordingly. So, if it's selling really well, it'll up the price by a little bit and if it's not selling at all, then it'll lower the price a little bit to see if we can get some sales coming in. Another thing you have is very easy inventory management. You can manage all of your inventory from one screen. So, if you click on over here where the products tab is, you're gonna see all of your inventory and a very handy feature within this is the ability to bulk edit. So, you can select everything you want and you can edit everything at once. From here, after you click the bulk edit, you're gonna see this screen. Once you're here, just click add item to edit and then you can edit any one of these options on all of the different products that you selected. So, if you wanna add an additional profit on all of the items, let's say you wanna add one or $2 per sale, you could click this right here, add $2. And if you ever run out of items to sell or just don't have any good ideas of what to include into your store, you don't have to worry about that because AutoDS also offers a very handy product research tool. Using product research tool, you can find highly popular and trending items in no time. Now, after you find those products, there's also a research spreadsheet that we offer that can help you optimize all of those listings. Now, if you want access to that spreadsheet, make sure to leave a comment down below requesting it and I'll be sure to link it for you. Now, last but certainly not least is the advanced AutoDS image editor. This really helps your listings and the images in your listings stand out from the competition. Using this editor, you can really optimize your listings by adding text, adding icons, drawing on the image, whatever you need to do, you can do using this image editor. Using all of these tools that AutoDS offers can really help you streamline the entire process of getting your store open running. Having all that extra time on your hands can really help you start to scale your business even more or take some time off and spend it with the family. With that, we have reached the end of this video. If you found this information useful, if you found it all helpful and you want to keep learning more about the dropshipping business, make sure to hit that subscribe button, make sure to leave a like. And once again, my name is Mario with AutoDS, wishing you all nothing but success in your dropshipping businesses and I'll catch you all in the next video.