Jim,
On 6/26/06 8:15 PM, Jim C. Nasby [EMAIL PROTECTED] wrote:
On a somewhat related note, I think that it would be advantageous if the
FSM had a means to prefer certain pages for a given tuple over other
pages. This would allow for a better way to keep heap and possibly index
data more
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 27 June 2006 05:12
To: Alvaro Herrera
Cc: Hackers
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Clamp
last_anl_tuples to n_live_tuples, in case we vacuum a table
Alvaro Herrera
Ühel kenal päeval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian:
Jim C. Nasby wrote:
On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
It is certainly possible to do what you are suggesting, that is have two
index entries point to same chain head, and have the index
Very nice explanation, thanks Alvaro.
2. Mark frozen databases specially somehow.
To mark databases frozen, we need a way to mark tables as frozen.
How do we do that? As I explain below, this allows some nice
optimizations, but it's a very tiny can full of a huge amount of
On Tue, 2006-06-27 at 10:04 +0200, Zeugswetter Andreas DCP SD wrote:
Simon wrote:
Suggest that we prevent write operations on Frozen tables by revoking
all INSERT, UPDATE or DELETE rights held, then enforcing a check during
GRANT to prevent them being re-enabled. Superusers would need to
My idea is that if an UPDATE places the new tuple on the same page as
the old tuple, it will not create new index entries for any indexes
where the key doesn't change.
Basically the idea behind preventing index bloat by updates is to have
one index tuple point to several actual tuples
Ühel kenal päeval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing:
Ühel kenal päeval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian:
Jim C. Nasby wrote:
On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
It is certainly possible to do what you are suggesting, that
Jim C. Nasby wrote:
On Sun, Jun 25, 2006 at 08:04:18PM -0400, Luke Lonergan wrote:
Other DBMS have index organized tables that can use either hash or btree
organizations, both of which have their uses. We are planning to
implement btree organized tables sometime - anyone else interested in
Suggest that we prevent write operations on Frozen tables by
revoking
all INSERT, UPDATE or DELETE rights held, then enforcing a check
during GRANT to prevent them being re-enabled. Superusers would need
to check every time. If we dont do this, then we will have two
Ühel kenal päeval, E, 2006-06-26 kell 11:31, kirjutas Bruce Momjian:
Hannu Krosing wrote:
pass 3: clean heap based on ctid from pass 1
If yo do it this way, you dont need to invent new data structures to
pass extra info about CITC internals to passes 2 and 3
On more
Hi
Is there anybody who knows about Turning off disk caching in solaris
machines.
If so, pl. reply back.
Thanks
Dhanaraj
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
test=# CREATE INDEX idxFTI_idx ON wikipedia USING gist(vector);
CREATE INDEX
Time: 416122.896 ms
so about 7 minutes - sounds very reasonable
test=# CREATE INDEX idxFTI2_idx ON wikipedia USING gin(vector);
CREATE INDEX
Time: 52681605.101 ms
I'll look at this, but GiST time creation is
Ãhel kenal päeval, E, 2006-06-26 kell 09:10, kirjutas Mark Woodward:
ÃÅhel kenal päeval, R, 2006-06-23 kell 17:27, kirjutas Bruce
Momjian:
Jonah H. Harris wrote:
On 6/23/06, Tom Lane [EMAIL PROTECTED] wrote:
What I see in this discussion is a huge amount of the grass must
be
On Fri, Jun 23, 2006 at 06:37:01AM -0400, Mark Woodward wrote:
While we all know session data is, at best, ephemeral, people still want
some sort of persistence, thus, you need a database. For mcache I have a
couple plugins that have a wide range of opitions, from read/write at
startup and
I have a PL/Java user that performs some lengthy operations. Eventually,
he get warnings like:
WARNING: buffer refcount leak: [779] (rel=1663/16440/52989, blockNum=3,
flags=0x27, refcount=1 2)
I traced this to the function PrintBufferLeakWarning. AFAICS, it's only
called from the function
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
That was with a mind to performance. Checking every INSERT,
UPDATE and DELETE statement to see if they are being done
against a frozen table seems like a waste.
I'd think we would have relminxid in the relcache, so I don't buy the
On Tue, Jun 27, 2006 at 03:55:06PM +0200, Thomas Hallgren wrote:
I have a PL/Java user that performs some lengthy operations. Eventually,
he get warnings like:
WARNING: buffer refcount leak: [779] (rel=1663/16440/52989, blockNum=3,
flags=0x27, refcount=1 2)
I think the comment about
Thomas Hallgren [EMAIL PROTECTED] writes:
I have a PL/Java user that performs some lengthy operations. Eventually,
he get warnings like:
WARNING: buffer refcount leak: [779] (rel=1663/16440/52989, blockNum=3,
flags=0x27, refcount=1 2)
Look for ReadBuffer calls not matched by ReleaseBuffer.
On Mon, Jun 26, 2006 at 11:29:27AM -0400, Bruce Momjian wrote:
Yes, and for index_getmulti (which doesn't visit the heap at all) we'll
have to change all the users of that (which aren't many, I suppose).
It's probably worth making a utility function to expand them.
I'm still confused
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
8192 too.
pqcomm.c:117
#define PQ_BUFFER_SIZE 8192
send() may take as long as 200ms. So,
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
send() may take as long as 200ms. So, I think we should increase
SO_SNDBUF to more than 8192. I attache the patch.
Why would that help? We won't be sending more than 8K at a time.
regards, tom lane
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
8192 too.
Ok, so
From: Tom Lane [EMAIL PROTECTED]
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 11:30:56 -0400
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
send() may take as long as 200ms. So, I think we should increase
SO_SNDBUF to more than 8192. I attache the patch.
Why
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Martijn van Oosterhout
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
On Tue, Jun 27, 2006 at 11:45:53AM -0400, Andrew Dunstan wrote:
No, it says it occurs if this condition is met: A single *send* call or
*WSASend* call fills the whole underlying socket send buffer.
This will surely be true if the buffer sizes are the same. They
recommend making the socket
Hannu Krosing wrote:
?hel kenal p?eval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing:
?hel kenal p?eval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian:
Jim C. Nasby wrote:
On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
It is certainly possible to do what
PFC wrote:
My idea is that if an UPDATE places the new tuple on the same page as
the old tuple, it will not create new index entries for any indexes
where the key doesn't change.
Basically the idea behind preventing index bloat by updates is to have
one index tuple point to
On Mon, Jun 26, 2006 at 11:08:24PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
It is certainly possible to do what you are suggesting, that is have two
index entries point to same chain head, and have the index access
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Mon, Jun 26, 2006 at 11:29:27AM -0400, Bruce Momjian wrote:
Yes, and for index_getmulti (which doesn't visit the heap at all) we'll
have to change all the users of that (which aren't many, I suppose).
It's probably worth
Jim C. Nasby wrote:
Perhaps my point got lost... in the case where no index keys change
during an update, SITC seems superior in every way to my proposal. My
idea (let's call it Index Tuple Page Consolidation, ITPC) would be
beneficial to UPDATEs that modify one or more index keys but
There's an inconsistency between the handling of trailing whitespace in
query parameters in the client jdbc driver compared to the PL/Java SPI
based driver. According to Jean-Pierre, the former apparently trims the
trailing spaces before passing the query (see below). What is the
correct
Andrew Dunstan [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
http://support.microsoft.com/kb/823764/EN-US/
No, it says it occurs if this condition is met: A single *send* call or
*WSASend* call fills the whole
On Tue, Jun 27, 2006 at 10:42:54AM +0200, PFC wrote:
Also, I insist (again) that there is a lot to gain by using a bit of
compression on the data pages, even if it's very simple compression like
storing the new version of a row as a difference from the previous version
(ie. only
From: Martijn van Oosterhout kleptog@svana.org
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 18:13:18 +0200
On Tue, Jun 27, 2006 at 11:45:53AM -0400, Andrew Dunstan wrote:
No, it says it occurs if this condition is met: A single *send* call or
*WSASend*
On Mon, Jun 26, 2006 at 11:31:24PM -0700, Luke Lonergan wrote:
Jim,
On 6/26/06 8:15 PM, Jim C. Nasby [EMAIL PROTECTED] wrote:
On a somewhat related note, I think that it would be advantageous if the
FSM had a means to prefer certain pages for a given tuple over other
pages. This would
From: Tom Lane [EMAIL PROTECTED]
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 12:28:35 -0400
Andrew Dunstan [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
I think one of the issues might have been: how will you handle other
indexes on the table when you can no longer point them at an item (since
items will need to move to maintain an IOT).
I guess you shouldn't allow any other indexes. That's a perfectly
acceptable compromise I think... it would
Sorry, wrong list... I reposted this on pgsql-jdbc instead.
---(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
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
It also says that the condition only occurs if the program uses
non-blocking sockets ... which the backend does not. So this page
offers no support for the proposed patch.
WSAEventSelect() sets a socket to
On Jun 27, 2006, at 9:39 AM, Jim C. Nasby wrote:
I think one of the issues might have been: how will you handle other
indexes on the table when you can no longer point them at an item
(since
items will need to move to maintain an IOT).
There are clean ways to handle this. The table is
From: Tom Lane [EMAIL PROTECTED]
It also says that the condition only occurs if the program uses
non-blocking sockets ... which the backend does not. So this page
offers no support for the proposed patch.
WSAEventSelect() sets a socket to nonblocking mode.
Yeah, but that socket
I've been digging into why buildfarm member thrush has been dumping core
consistently during the regression tests since the posix_fadvise patch
went in. I've confirmed that posix_fadvise() itself will SIGSEGV in a
standalone test program, and found that this happens only if
_FILE_OFFSET_BITS=64
Bruce Momjian [EMAIL PROTECTED] writes:
PFC wrote:
My idea is that if an UPDATE places the new tuple on the same page as
the old tuple, it will not create new index entries for any indexes
where the key doesn't change.
Basically the idea behind preventing index bloat by
I would set the SO_SNDBUF to 32768.
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
8192 too.
pqcomm.c:117
#define
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Wasn't this patch rejected?
Anyway, what is your opinion on this?
I thought we'd rejected it. I'm not sure that we'd completely agreed
what the best thing to do is, but what this patch actually does is to
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
PFC wrote:
My idea is that if an UPDATE places the new tuple on the same page as
the old tuple, it will not create new index entries for any indexes
where the key doesn't change.
Basically the idea behind
Tom Lane wrote:
I've been digging into why buildfarm member thrush has been dumping core
consistently during the regression tests since the posix_fadvise patch
went in. I've confirmed that posix_fadvise() itself will SIGSEGV in a
standalone test program, and found that this happens only if
Magnus Hagander [EMAIL PROTECTED] writes:
We use non-blocking sockets in backend/port/win32/socket.c so we are
able to deliver our faked signals while waiting for I/O on the socket.
We specifically set it in pgwin32_socket().
Hm, that seems a bit grotty, but anyway I stand corrected.
Given
We have definitly seen weird timing issues sometimes when both client
and server were on Windows, but have been unable to pin it exactly on
what. From Yoshiykis other mail it looks like this could possibly be it,
since he did experience a speedup in the range we've been looking for in
those
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
While we could possibly come up with a suitable configure test to
determine whether posix_fadvise is actually safe to use on a given
system, I think we should seriously consider just reverting the patch.
As far as I saw, zero evidence
Teodor Sigaev wrote:
test=# CREATE INDEX idxFTI_idx ON wikipedia USING gist(vector);
CREATE INDEX
Time: 416122.896 ms
so about 7 minutes - sounds very reasonable
test=# CREATE INDEX idxFTI2_idx ON wikipedia USING gin(vector);
CREATE INDEX
Time: 52681605.101 ms
I'll look at this, but
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add GUC update_process_title to control whether 'ps' display is updated
for every command, default to on.
It strikes me that the ps_status support provides one important bit of
information that is currently hard to get elsewhere; specifically, the
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add GUC update_process_title to control whether 'ps' display is updated
for every command, default to on.
It strikes me that the ps_status support provides one important bit of
information that is currently hard to get elsewhere;
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add GUC update_process_title to control whether 'ps' display is updated
for every command, default to on.
It strikes me that the ps_status support provides one important bit of
information that is currently hard to get elsewhere;
* Tom Lane ([EMAIL PROTECTED]) wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add GUC update_process_title to control whether 'ps' display is updated
for every command, default to on.
It strikes me that the ps_status support provides one important bit of
information that is currently
* Stephen Frost ([EMAIL PROTECTED]) wrote:
That would be an *excellent* addition.. Honestly, I think it'd be nice
to get a 'NOTICE' in such cases too, but having it in pg_stat_activity
will help alot.
Additionally, Tom, and I hate to point this out here but I don't see
much of an alternative;
-- liuchao
Jim,
I know there were discussions in the past, though as per usual I can't
find them in the archives.
Search on B-Tree Organized Tables.
From what I can find, this feature isn't prohibitively useless. It's just a
singnificant amount of effort for a result which is a tradeoff. That is,
Bruce,
Do we have anything in the pipeline that would result in page format changes
for 8.2? I'm wondering if it's worth reviving pg_upgrade, folks at work are
interested ...
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of
Josh Berkus josh@agliodbs.com writes:
Do we have anything in the pipeline that would result in page format changes
for 8.2?
[ looks at
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h
]
I don't see any page format changes per se, but inet/cidr datatype
61 matches
Mail list logo
