[PATCHES] Updated bitmap index patch
Hi all, I've updated the bitmap index patch. It can be found here: http://www.alcove.com.au/~swm/bitmap-2007-03-12.diff This fixes some bugs introduced in the last patch, catches up to HEAD and tidies up the executor code. I want to do a little more tidying, such as reverting the name changes we made. multiscan still sounds alright. I've been thinking about vacuum as well. Something along the lines of what Heikki mentioned earlier -- namely, the ability to iterate the bitmap setbit by setbit is in order. What I have in mind, though, is that when we find a reaped setbit, we mark the position and continue to iterate until we find a non reaped setbit. When, we update the underlying bitmap vector to reflect the non-set bits. Thoughts? Thanks, Gavin ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Updated bitmap index patch
I don't very like GiST changes: gistgetbitmap will lock/unlock page for every tuple. It seems to me taht is better to change gistnext function to use some sort callback, for example. Or have static array for tids in gistgetbitmap... -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Updated bitmap index patch
Gavin Sherry wrote: Hi all, I've updated the bitmap index patch. It can be found here: http://www.alcove.com.au/~swm/bitmap-2007-03-12.diff This fixes some bugs introduced in the last patch, catches up to HEAD and tidies up the executor code. I want to do a little more tidying, such as reverting the name changes we made. multiscan still sounds alright. Thanks, I'll take a look at it. I just posted a patch to change the getmulti API. Please have a look at that and say what you think. I don't want to deliberately bitrot your patch, but on the other hand I do want to get the candidate matches support in before the bitmap index am, because reviewing and committing that can take a long time. I've been thinking about vacuum as well. Something along the lines of what Heikki mentioned earlier -- namely, the ability to iterate the bitmap setbit by setbit is in order. What I have in mind, though, is that when we find a reaped setbit, we mark the position and continue to iterate until we find a non reaped setbit. When, we update the underlying bitmap vector to reflect the non-set bits. Ok. It's going to be opaque to the caller of the iterate-function anyway, right? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Bitmapscan changes
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > The patch also adds support for candidate matches. An index scan can > indicate that the tuples it's returning are candidates, and the executor > will recheck the original scan quals of any candidate matches when the > tuple is fetched from heap. This will not work, unless we change the planner --- the original quals aren't necessarily there in some corner cases (partial indexes, if memory serves). > The motivation for adding the support for candidate matches is that GIT > / clustered indexes need it. You need more than a vague reference to an unapplied patch to convince me we ought to do this. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Bitmapscan changes
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: The patch also adds support for candidate matches. An index scan can indicate that the tuples it's returning are candidates, and the executor will recheck the original scan quals of any candidate matches when the tuple is fetched from heap. This will not work, unless we change the planner --- the original quals aren't necessarily there in some corner cases (partial indexes, if memory serves). This is only for bitmap scans, which *do* always have the original quals available in the executor (BitmapHeapScanState.bitmapqualorig). That's because we have to recheck the original conditions when the bitmap goes lossy. To support candidate matches with the amgettuple API, that'll need to be changed as well. And that will indeed involve more executor changes. The motivation for adding the support for candidate matches is that GIT / clustered indexes need it. You need more than a vague reference to an unapplied patch to convince me we ought to do this. With the unapplied GIT patch, the index doesn't store the index key of every tuple. That has the consequence that when scanning, we get a bunch of tids to a heap page, we know that some of the might match, but we don't know which ones until the tuples are fetched from heap. In a more distant future, range-encoded bitmap indexes will also produce candidate matches. And as I mentioned, this is immediately useful when doing bitmap ANDs large enough to go lossy. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Bitmapscan changes
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> This will not work, unless we change the planner --- the original quals >> aren't necessarily there in some corner cases (partial indexes, if >> memory serves). > This is only for bitmap scans, which *do* always have the original quals >available in the executor (BitmapHeapScanState.bitmapqualorig). > That's because we have to recheck the original conditions when the > bitmap goes lossy. Yeah, but the index AM has to support regular indexscans too, and those are not prepared for runtime lossiness determination; nor am I particularly willing to add that. > With the unapplied GIT patch, the index doesn't store the index key of > every tuple. I thought the design was to eliminate *duplicate* keys from the index. Not to lose data. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Bitmapscan changes
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: This will not work, unless we change the planner --- the original quals aren't necessarily there in some corner cases (partial indexes, if memory serves). This is only for bitmap scans, which *do* always have the original quals available in the executor (BitmapHeapScanState.bitmapqualorig). That's because we have to recheck the original conditions when the bitmap goes lossy. Yeah, but the index AM has to support regular indexscans too, and those are not prepared for runtime lossiness determination; nor am I particularly willing to add that. Well, do you have an alternative suggestion? With the unapplied GIT patch, the index doesn't store the index key of every tuple. I thought the design was to eliminate *duplicate* keys from the index. Not to lose data. The idea *isn't* to deal efficiently with duplicate keys. The bitmap indexam is better suited for that. The idea really is to lose information from the leaf index pages, in favor of a drastically smaller index. On a completely clustered table, the heap effectively is the leaf level of the index. I'm glad we're having this conversation now. I'd really appreciate review of the design. I've been posting updates every now and then, asking for comments, but never got any. If you have suggestions, I'm all ears and I still have some time left before feature freeze to make changes. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Bitmapscan changes
Heikki Linnakangas <[EMAIL PROTECTED]> writes: >>> With the unapplied GIT patch, the index doesn't store the index key of >>> every tuple. >> >> I thought the design was to eliminate *duplicate* keys from the index. >> Not to lose data. > The idea really is to lose information from the leaf index pages, in > favor of a drastically smaller index. On a completely clustered table, > the heap effectively is the leaf level of the index. I'm really dubious that this is an intelligent way to go. In the first place, how will you keep the index sorted if you can't determine the values of all the keys? It certainly seems that this would break the ability to have a simple indexscan return sorted data, even if the index itself doesn't get corrupted. In the second place, this seems to forever kill the idea of indexscans that don't visit the heap --- not that we have any near-term prospect of doing that, but I know a lot of people remain interested in the idea. The reason this catches me by surprise is that you've said several times that you intended GIT to be something that could just be enabled universally. If it's lossy then there's a much larger argument that not everyone would want it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Packed varlena patch update
I implemented Tom's suggestion of packing the external toast pointers unaligned and copying them to a local struct to access the fields. This saves 3-6 bytes on every external toast pointer. Presumably this isn't interesting if you're accessing the toasted values since they would be quite large anyways, but it could be interesting if you're doing lots of queries that don't access the toasted values. It does uglify the code a bit but it's all contained in tuptoaster.c. http://community.enterprisedb.com/varlena/patch-varvarlena-19.patch.gz I think this is the last of the todo suggestions that were mentioned on the list previously, at least that I recall. Some implications: 1) There's no longer any macro to determine if an external attribute is compressed. I could provide a function to do it if we need it but in all the cases where I see it being used we already needed to extract the fields of the toast pointer anyways, so it wouldn't make sense. 2) We check if a toasted value is replaced with a new one by memcmp'ing the entire toast pointer. We used to just compare valueid and relid, so this means we're now comparing extsize and rawsize as well. I can't see how they could vary for the same valueid though so I don't think that's actually changing anything. Remaining things in the back of my mind though: . I'm not 100% confident of the GIST changes. I think I may have changed a few too many lines of code there. It does pass all the contrib regressions though. . I think there may be some opportunities for optimizing heaptuple.c. In particular the places where it uses VARSIZE_ANY where it knows some of the cases are impossible. It may not make a difference due to branch prediction though. . I've left the htonl/ntohl calls in place in the BIG_ENDIAN #if-branch. They're easy enough to remove and it leaves us the option of removing the #if entirely and just us use network-byte-order instead of the #ifdef. I'm a bit worried about modules building against postgres.h without including the config.h include file. Is that possible? Is it worth worrying about? I think I could make it fail to build rather than crash randomly. . One of the regression tests I wrote makes a datum of 1/2Meg. Can all the build-farm machines handle that? I don't really need anything so large for the regression but it was the most convenient way to make something which after compressing was large enough to toast externally. It might be better to find some less compressible data. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Bitmapscan changes
Tom Lane wrote: I'm really dubious that this is an intelligent way to go. In the first place, how will you keep the index sorted if you can't determine the values of all the keys? It certainly seems that this would break the ability to have a simple indexscan return sorted data, even if the index itself doesn't get corrupted. That's indeed a very fundamental thing with the current design. The index doesn't retain the complete order within heap pages. That information is lost, again in favor of a smaller index size. It incurs a significant CPU overhead, but on an I/O bound system that's a tradeoff you want to make. At the moment, I'm storing the offsets within the heap in a bitmap attached to the index tuple. btgettuple fetches all the heap tuples represented by the grouped index tuple, checks their visibility, sorts them into index order, and returns them to the caller one at a time. Thats ugly, API-wise, because it makes the indexam to actually go look at the heap, which it shouldn't have to deal with. Another approach I've been thinking of is to store a list of offsets, in index order. That would avoid the problem of returning sorted data, and reduce the CPU overhead incurred by sorting and scanning, at the cost of much larger (but still much smaller than what we have now) index. > In the second place, this seems to forever kill the idea of indexscans that don't visit the heap --- not that we have any near-term prospect of doing that, but I know a lot of people remain interested in the idea. I'm certainly interested in that. It's not really needed for clustered indexes, though. A well-clustered index is roughly one level shallower, and the heap effectively is the leaf-level, therefore the amount of I/O you need to fetch the index tuple + heap tuple, is roughly the same that as fetching just the index tuple from a normal b-tree index. On non-clustered indexes, index-only scans would of course still be useful. The reason this catches me by surprise is that you've said several times that you intended GIT to be something that could just be enabled universally. If it's lossy then there's a much larger argument that not everyone would want it. Yeah, we can't just always enable it by default. While a clustered index would degrade to a normal b-tree when the heap isn't clustered, you would still not want to always enable the index clustering because of the extra CPU overhead. That has become clear in the CPU bound tests I've run. I think we could still come up with some safe condiitions when we could enable it by default, though. In particular, I've been thinking that if you run CLUSTER on a table, you'd definitely want to use a clustered index as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Bitmapscan changes
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> In the second place, this seems to >> forever kill the idea of indexscans that don't visit the heap --- not >> that we have any near-term prospect of doing that, but I know a lot of >> people remain interested in the idea. > I'm certainly interested in that. It's not really needed for clustered > indexes, though. A well-clustered index is roughly one level shallower, > and the heap effectively is the leaf-level, therefore the amount of I/O > you need to fetch the index tuple + heap tuple, is roughly the same that > as fetching just the index tuple from a normal b-tree index. That argument ignores the fact that the heap entries are likely to be much wider than the index entries, due to having other columns in them. > I think we could still come up with some safe condiitions when we could > enable it by default, though. At this point I'm feeling unconvinced that we want it at all. It's sounding like a large increase in complexity (both implementation-wise and in terms of API ugliness) for a fairly narrow use-case --- just how much territory is going to be left for this between HOT and bitmap indexes? I particularly dislike the idea of having the index AM reaching directly into the heap --- we should be trying to get rid of that, not add more cases. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Bitmapscan changes
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: In the second place, this seems to forever kill the idea of indexscans that don't visit the heap --- not that we have any near-term prospect of doing that, but I know a lot of people remain interested in the idea. I'm certainly interested in that. It's not really needed for clustered indexes, though. A well-clustered index is roughly one level shallower, and the heap effectively is the leaf-level, therefore the amount of I/O you need to fetch the index tuple + heap tuple, is roughly the same that as fetching just the index tuple from a normal b-tree index. That argument ignores the fact that the heap entries are likely to be much wider than the index entries, due to having other columns in them. True, that's the "roughly" part. It does indeed depend on your schema. As a data point, here's the index sizes (in pages) of a 140 warehouse TPC-C database: index name normal grouped % of normal size -- i_customer 31984 29250 91.5% i_orders11519 11386 98.8% pk_customer 11519 1346 11.6% pk_district 6 2 pk_item 276 103.6% pk_new_order 3458 421.2% pk_order_line 153632 29931.9% pk_orders 115191911.7% pk_stock38389 28157.3% pk_warehouse8 2 The customer table is an example of pretty wide table, there's only ~12 tuples per page. pk_customer is still benefiting a lot. i_customer and i_orders are not benefiting because the tables are not in the index order. The orders-related indexes are seeing the most benefit, they don't have many columns. I think we could still come up with some safe condiitions when we could enable it by default, though. At this point I'm feeling unconvinced that we want it at all. It's sounding like a large increase in complexity (both implementation-wise and in terms of API ugliness) for a fairly narrow use-case --- just how much territory is going to be left for this between HOT and bitmap indexes? I don't see how HOT is overlapping with clustered indexes. On the contrary, it makes clustered indexes work better, because it reduces the amount of index inserts needed and helps to keep a table clustered. The use cases for bitmap indexes and clustered indexes do overlap somewhat. But clustered indexes have an edge because: - there's no requirement of having only a small number of distinct values - they support uniqueness checks - you can efficiently have a mixture of grouped and non-grouped tuples, if your table is only partly clustered In general, clustered indexes are more suited for OLTP work than bitmap indexes. I particularly dislike the idea of having the index AM reaching directly into the heap --- we should be trying to get rid of that, not add more cases. I agree. The right way would be to add support for partial ordering and candidate matches to the indexam API, and move all the sorting etc. ugliness out of the indexam. That's been on my TODO since the beginning. If you're still not convinced that we want this at all, how would you feel about the another approach I described? The one where the in-heap-page order is stored in the index tuples, so there's no need for sorting, at the cost of losing part of the I/O benefit. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Packed varlena patch update
Gregory Stark wrote: > I'm a bit worried about modules building against postgres.h without > including the config.h include file. Is that possible? Is it worth worrying > about? I think I could make it fail to build rather than crash randomly. postgres.h includes c.h which includes pg_config.h, so this is not a problem. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Bitmapscan changes
Heikki Linnakangas wrote: Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: In the second place, this seems to forever kill the idea of indexscans that don't visit the heap --- not that we have any near-term prospect of doing that, but I know a lot of people remain interested in the idea. I'm certainly interested in that. It's not really needed for clustered indexes, though. A well-clustered index is roughly one level shallower, and the heap effectively is the leaf-level, therefore the amount of I/O you need to fetch the index tuple + heap tuple, is roughly the same that as fetching just the index tuple from a normal b-tree index. That argument ignores the fact that the heap entries are likely to be much wider than the index entries, due to having other columns in them. True, that's the "roughly" part. It does indeed depend on your schema. As a data point, here's the index sizes (in pages) of a 140 warehouse TPC-C database: Ah, I see now that you didn't (necessarily) mean that the clustering becomes inefficient at reducing the index size on wider tables, but that there's much more heap pages than leaf pages in a normal index. That's true, you might not want to use clustered index in that case, to allow index-only scans. If we had that feature, that is. Often, though, when using index-only scans, columns are added to the index to allow them to be returned in an index-only scans. That narrows the gap a bit. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Bitmapscan changes
On Mon, 2007-03-12 at 13:56 -0400, Tom Lane wrote: > At this point I'm feeling unconvinced that we want it at all. It's > sounding like a large increase in complexity (both implementation-wise > and in terms of API ugliness) for a fairly narrow use-case --- just > how much territory is going to be left for this between HOT and bitmap > indexes? HOT and clustered indexes have considerable synergy. In many tests we've got +20% performance with them acting together. Neither one achieves this performance on their own, but together they work very well. There is an overlap between clustered and bitmap indexes, but they come at the problem from different ends of the scale. Bitmap indexes are designed to cope well with highly non-unique data, while clustered indexes optimise for unique or somewhat unique keys. The difference is really bitmap for DW and clustered indexes for OLTP. The ideas for bitmap indexes come from research and other RDBMS implementations. Clustered indexes have also got external analogs - the concepts are very similar to SQLServer Clustered Indexes and Teradata Primary Indexes (Block Index structure), as well as being reasonably close to Oracle's Index Organised Tables. Clustered indexes offer a way to reduce index size to 1-5% of normal b-tree sizes, yet still maintaining uniqueness checking capability. For VLDB, that is a win for either OLTP or DW - think about a 1 TB index coming down to 10-50 GB in size. The benefit is significant for most tables over a ~1 GB in size through I/O reduction on leaf pages. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Bitmapscan changes
Simon Riggs wrote: On Mon, 2007-03-12 at 13:56 -0400, Tom Lane wrote: At this point I'm feeling unconvinced that we want it at all. It's sounding like a large increase in complexity (both implementation-wise and in terms of API ugliness) for a fairly narrow use-case --- just how much territory is going to be left for this between HOT and bitmap indexes? HOT and clustered indexes have considerable synergy. In many tests we've got +20% performance with them acting together. Neither one achieves this performance on their own, but together they work very well. To clarify, Simon is talking about DBT-2 tests we run in November. Clustered indexes don't require HOT per se, but on TPC-C the performance benefit comes from reducing the amount of I/O on the stock table and index, and that's a table that gets updated at a steady rate. Without HOT, the updates will disorganize the table and the performance gain you get from clustered indexes vanishes after a while. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] guc patch: Make variables fall back to default values
Joachim Wieland wrote: > Attached is the long-awaited guc patch that makes values fall back to > their default values when they got removed (or commented) from the > configuration file. This has always been a source of confusion. I have applied your patch with some of the discussed corrections. The use of memory allocation in the GUC code might still need some review. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] guc patch: Make variables fall back to default values
"Peter Eisentraut" <[EMAIL PROTECTED]> writes: > Joachim Wieland wrote: >> Attached is the long-awaited guc patch that makes values fall back to >> their default values when they got removed (or commented) from the >> configuration file. This has always been a source of confusion. > > I have applied your patch with some of the discussed corrections. The > use of memory allocation in the GUC code might still need some review. This is a pretty major user-visible change. While I'm strongly in favour of it it seems like there ought to be some documentation file touched by this, no? Or have I missed it? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Updated bitmap index patch
Teodor, On Mon, 12 Mar 2007, Teodor Sigaev wrote: > I don't very like GiST changes: gistgetbitmap will lock/unlock page for every > tuple. It seems to me taht is better to change gistnext function to use some > sort callback, for example. Or have static array for tids in gistgetbitmap... Good point. I'll look at it. Thanks Gavin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Bitmapscan changes
On Mon, 12 Mar 2007, Heikki Linnakangas wrote: > Here's a patch to change the amgetmulti API so that it's called only > once per scan, and the indexam adds *all* matching tuples at once to a > caller-supplied TIDBitmap. Per Tom's proposal in July 2006: > http://archives.postgresql.org/pgsql-hackers/2006-07/msg01233.php I incorporated something like your change to gistnext(). This is much better, for the reason Teodor mentions up thread. The return type of gistnext() is int and it is possible that it could overflow (on some platforms) now that there is no max_tids. Thanks, Gavin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] pgbench on mingw needs fflush
pgbench reports its progress of loading ("N tuples done.") or vacuuming
("vacuum...end"), but the messages are not printed on the moment on mingw.
The reason seems to be the buffering of stderr. This patch adds fflush()
just after each fprintf(stderr).
The buffered stderr might be a bug of mingw, but redundant fflush()
does not make mischief for platforms that have correct stderr.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
pgbench.fflush.diff
Description: Binary data
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgbench on mingw needs fflush
Can we distinguish mingw case from others so that we could ifdef out
the extra fflush()?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> pgbench reports its progress of loading ("N tuples done.") or vacuuming
> ("vacuum...end"), but the messages are not printed on the moment on mingw.
> The reason seems to be the buffering of stderr. This patch adds fflush()
> just after each fprintf(stderr).
>
> The buffered stderr might be a bug of mingw, but redundant fflush()
> does not make mischief for platforms that have correct stderr.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] pgbench on mingw needs fflush
Can we distinguish mingw case from others so that we could ifdef out
the extra fflush()?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> pgbench reports its progress of loading ("N tuples done.") or vacuuming
> ("vacuum...end"), but the messages are not printed on the moment on mingw.
> The reason seems to be the buffering of stderr. This patch adds fflush()
> just after each fprintf(stderr).
>
> The buffered stderr might be a bug of mingw, but redundant fflush()
> does not make mischief for platforms that have correct stderr.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] guc patch: Make variables fall back to default values
Gregory Stark wrote: > This is a pretty major user-visible change. While I'm strongly in > favour of it it seems like there ought to be some documentation file > touched by this, no? Or have I missed it? In my opinion, and possibly that of others who have worked on this issue, the old behavior was a pretty much a bug and now it works as expected. Not sure how to document that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgbench on mingw needs fflush
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Can we distinguish mingw case from others so that we could ifdef out > the extra fflush()? Isn't the right fix a single-spot patch to force stderr into unbuffered mode? It's supposed to be that way already per spec. I could see a one-or-two-line patch to remind mingw of the buffer mode it's supposed to be using ... I'm not excited about making an ongoing commitment to remember to fflush() after every write call, especially not when no standard-compliant platform needs it. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
