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 t
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 wa
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
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
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,
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-hacker
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 p
"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 appl
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. T
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
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 b
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
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_confi
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.
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 c
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 ind
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
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 inde
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 o
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
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 f
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.
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
reverti
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: [EM
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
25 matches
Mail list logo
