Josh Berkus 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
representation changed
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 broadcast)--
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
-- liuchao
* 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 alternativ
* 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 curre
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; specif
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 elsew
[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
"wai
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 l
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 e
> 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
> tho
"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.
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
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.
> > >
> > > Ba
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
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 PQ
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 i
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 ..
> > 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,
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 org
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
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
> 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 wou
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:
> >>> http://suppo
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
From: Martijn van Oosterhout
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* call fills the
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
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 wh
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 behavi
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 inde
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
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 in
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 poi
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
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 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.
> >
>
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
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
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.
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
-
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,
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
silently remove the depend
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 co
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 ReleaseBu
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 f
"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 t
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 Re
> 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
>> startu
> Ã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 o
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 suspicio
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
Ü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
> > >
> > > 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
> >
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
t
Ü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 sugge
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 havin
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
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
>
Ü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
> -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 H
61 matches
Mail list logo
