Here is the next patch version. The naming and style concerns have been addressed. The patch now only touches 5 files. 4 of those files are hashjoin specific and 1 is to add a couple lines to a hashjoin specific struct in another file.
The code can now find the the MCVs in more cases. Even if the probe side is an operator other than a seq scan (such as another hashjoin) the code can now find the stats tuple for the underlying relation. The new idea of limiting the number of MCVs to a percentage of memory has not been added yet. - Bryce Cutt On Mon, Dec 29, 2008 at 8:55 PM, Robert Haas <robertmh...@gmail.com> wrote: >> I think that setting aside a minimum percentage of work_mem may be a >> reasonable approach. For instance, setting aside 1% at even 1 MB >> work_mem would be 10 KB which is enough to store about 40 MCV tuples of >> the TPC-H database. Such a small percentage would be very unlikely (but >> still possible) to change the number of batches used. Then, given the >> memory allocation and the known tuple size + overhead, only that number >> of MCVs are selected for the MCV table regardless how many there are. >> The MCV table size would then increase as work_mem is changed up to a >> maximum given by the number of MCVs. > > Sounds fine. Maybe 2-3% would be better. > >> The code when building the MCV hash table keeps track of the order of >> insertion of the best MCVs. It then flushes the MCV partitions in >> decreasing order of frequency of MCVs. Thus, by the end of the build >> partitioning phase the MCV hash table should only store the most >> frequent MCV tuples. Even with many-to-many joins as long as we keep >> all build tuples that have a given MCV in memory, then everything is >> fine. You would get into problems if you only flushed some of the >> tuples of a certain MCV but that will not happen. > > OK, I'll read it again - I must not have understood. > > It would be good to post an updated patch soon, even if not everything > has been addressed. > > ...Robert >
histojoin_v4.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
