> I am sorry in a very late reaction...
No problem.
> > >>> We'll need a VC buildfarm member in place to catch us
> anytime we
> > >>> change the Makefiles in a way that the script doesn't
> understand.
> > >>
> > >> Not a problem - Snake has VC++ 6, 2003 and 2005 installed.
>
> This is
> It turns out the problem is that port/pipe.c is compiled with
> -DFRONTEND and include/port/win32.h wraps the recv to
> pgwin32_recv macro in a #ifndef FRONTEND. We've actually
> been using the WinSock recv function directly (verified with gcc -E).
That's definitly wrong.
Looks like this fi
Here's a patch that implements page at a time index scans discussed at
pgsql-hackers earlier. See proposal 1 at:
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01237.php
It passes regression tests, and there's no known bugs. There's
some minor issues I'd like to point out, though:
1.
I saw the following in the TODO list.
clients-psql
1. Have psql show current values for a sequence
Hence, this patch displays the current seq. value in a separate column when \ds
is executed.
I attach the patch here. The display format may have to be changed. I would
like to chan
On Mon, 2006-05-01 at 22:00 +0300, Heikki Linnakangas wrote:
> Here's a patch that implements page at a time index scans discussed at
> pgsql-hackers earlier. See proposal 1 at:
> http://archives.postgresql.org/pgsql-hackers/2006-03/msg01237.php
>
> It passes regression tests, and there's no know
On Tue, 2 May 2006, Simon Riggs wrote:
On Mon, 2006-05-01 at 22:00 +0300, Heikki Linnakangas wrote:
1. An index scan now needs to allocate enough memory to hold potentially a
whole page worth of items. And if you use markpos/restrpos, twice that
much. I don't know if that's an issue, but I tho
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Also, could we calculate a better estimate of the maximum number of
> offsets an index page can hold?
We could make something analogous to MaxHeapTuplesPerPage --- the
correct number ought to be approximately BLCKSZ/16 I should think.
(It's not pos
As long as we have a Win32 test server around, I'm happy to help.
If you have a multi-processor development server, it's easy to recreate
though. Just load up the server (pgbench is fine) and wait a few
minutes. Single processor machines don't seem to be affected.
Pete
>>> "Magnus Hagander" <[
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Here's a patch that implements page at a time index scans discussed at
>> pgsql-hackers earlier. See proposal 1 at:
>> http://archives.postgresql.org/pgsql-hackers/2006-03/msg01237.php
One potential performance lossage from this is that it partial
I take that back. My local Postgres just didn't have stats_block_level
and stats_row_level turned on. It happens on single processor machines
too.
Pete
>>> "Peter Brant" <[EMAIL PROTECTED]> 05/02/06 6:29 pm >>>
minutes. Single processor machines don't seem to be affected.
---
I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Now that I look at it: Why do we have a separate vacuum_cleanup function
>> at all? Calls to index_vacuum_cleanup go hand in hand with calls to
>> index_bulk_delete.
> Yeah, I was just thinking we ought to revisit that. The original i
On Tue, 2 May 2006, Tom Lane wrote:
Also, as noted in other contexts, it'd be a good idea if vacuumcleanup
was told the total number of heap tuples (GIN needs this), and both
steps really ought to be able to find out if it's a full or lazy vacuum.
It's already in IndexVacuumCleanupInfo, isn't
Larry Rosenman wrote:
> Greetings,
> I've got a patch to be reviewed for having the stats system keep
> track of the last
> time a table was vacuumed or analyzed either by the user or via
> AutoVacuum.
>
> The patch is at:
> http://www.lerctr.org/~ler/pg-dev/vacuum-autovacuum-times-stats.diff
On Tue, 2 May 2006, Tom Lane wrote:
Agreed. The pin has two functions:
- keep the page from being moved out of the bufmgr - no need anymore
- stop a vacuum from removing the page - no need anymore. We'll not stop
on a removable row anymore, so no need.
At the moment, backward scan returns to
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Tue, 2 May 2006, Tom Lane wrote:
>> Also, as noted in other contexts, it'd be a good idea if vacuumcleanup
>> was told the total number of heap tuples (GIN needs this), and both
>> steps really ought to be able to find out if it's a full or lazy v
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Tue, 2 May 2006, Tom Lane wrote:
>> Backwards scan may break this whole concept; are you sure you've thought
>> it through?
> I think so. The patch doesn't change the walk-left code. Do you have
> something specific in mind?
I'm worried about s
16 matches
Mail list logo
