On Tue, 2007-03-27 at 20:48 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > It seems possible to reduce overall WAL volume by roughly 25% on common
> > workloads by optimising the way UPDATE statements generate WAL.
>
> This seems a huge amount of work to optimize *one* benc
On 2007-03-27, David Fetter <[EMAIL PROTECTED]> wrote:
> Per further discussion with Andrew of Supernews and Merlin Moncure,
> I've added a check for compound types and moved the creation of the
> array type from DefineRelation in backend/commands/tablecmds.c to
> heap_create_with_catalog in backen
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> IIRC, we're still waiting for performance numbers showing there exists a
> win from this patch.
Here is a performance number of Direct I/O support on Windows.
There was 10%+ of performance win on pgbench (263.33 vs. 290.79) in O_DIRECT.
However, I onl
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 3/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
>> the same as RelationInitIndexAccessInfo does?
> I tried that initially, but it gets into infinite recursion during initdb.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... random backend code should not, not, not be using fopen()
>> directly. If you lose control to an elog, which is certainly possible
>> seeing that this loop calls into the utils/mb subsystem, you'll leak
>> the file descriptor. Us
Bruce,
> However, with feature freeze coming on Sunday, I am worried because
> there are a significant number of patches that have are not ready for
> review because they have not been completed by their authors.
Can you flag those somehow?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---
On 3/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as RelationInitIndexAccessInfo does?
I tried that initially, but it gets into infinite recursion during initdb.
And what's the point of
the extra tuple cop
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
Seems to be a genuine bug. Fixed, but I see a worse problem with this
code: rand
Simon;
Thanks a lot for your comments/advices. I'd like to write some feedback.
Simon Riggs wrote:
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
a
Neil Conway <[EMAIL PROTECTED]> writes:
> In CVS HEAD:
> contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
> in this function
> Induced by the recent pg_verifymbstr() patch.
Seems to be a genuine bug. Fixed, but I see a worse problem with this
code: random backend code shoul
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Here is a patch which fixes this. We re-read part of the pg_index
> row and update rd_index with the new data. I tested REINDEX and CIC
> and both seems to work fine with the patch applied.
> Tom, does this look good ?
It seems a bit brute-force. W
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they hav
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I would love, love, love to be able to use this syntax within pg_dump as
> well, so we can create multiple indexes in parallel at restore time.
I can hardly conceive of greater folly than putting an *experimental*
psql facility into pg_dump scripts, ther
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> It seems possible to reduce overall WAL volume by roughly 25% on common
> workloads by optimising the way UPDATE statements generate WAL.
This seems a huge amount of work to optimize *one* benchmark. If it
weren't so narrowly focused on the properties o
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Included is a more eloborate example, which has some webby thing at
> http://www.familiedobbelsteen.nl/printer-test/ (should work).
Much too elaborate - I'm sorry, but I don't think anyone here is willing
to wade through nearly 900 lines of
Hi Josh-san.
From: "Josh Berkus"
Hiroshi,
We are doing the support including the trouble. It was thought that the
place of JPUG was preferable for the reasons why they were problems too
peculiar to Japan.
Well, some of PostgreSQL's commercial distributors have been pretty
surprised when
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http:/
Hiroshi,
> We are doing the support including the trouble. It was thought that the
> place of JPUG was preferable for the reasons why they were problems too
> peculiar to Japan.
Well, some of PostgreSQL's commercial distributors have been pretty
surprised when they package PostgreSQL and find ou
Simon Riggs wrote:
On Tue, 2007-03-27 at 17:11 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be abl
On Tue, 2007-03-27 at 17:11 -0400, Andrew Dunstan wrote:
> Simon Riggs wrote:
> >
> > I would love, love, love to be able to use this syntax within pg_dump as
> > well, so we can create multiple indexes in parallel at restore time.
> > Anyone fancy adding that as well? We should be able to speed up
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be able to speed up overall
index builds by x2 using concurrent builds.
You will need
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
> Here's an update of a code to improve full page writes as proposed in
>
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
> and
> http://archives.postgresql.org/pgsql-patches/2007-01/msg00607.php
>
> Update includes some
David Fetter wrote:
It now initdb's successfully, but fails on a lot of regression tests.
Please find attached the new patch vs. CVS TIP and the regression test
output.
The regression test output is useless without seeing the regression diffs.
cheers
andrew
---
On Fri, 2007-02-23 at 12:07 -0800, Ron Mayer wrote:
> Jim Nasby wrote:
> > The problem with using simple OS priority settings is you leave yourself
> > wide open to priority inversion.
>
> Which is why you either
> (a) note that papers studying priority inversion on RDBMS's
> find that it's
On Tue, 2007-03-27 at 18:16 +0100, Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Yes, yes. I would like to have used it when testing the MyProc->xmin
> > improvements. The only thing that has held it back from being applied
> > was that there was no documentation/examples of how it would b
>-Original Message-
>From: Hannu Krosing [mailto:[EMAIL PROTECTED]
>Sent: dinsdag 27 maart 2007 15:45
>To: Joris Dobbelsteen
>Cc: pgsql-hackers@postgreSQL.org
>Subject: Re: [HACKERS] Guarenteeing complex referencial
>integrity throughcustom triggers
>
>Ühel kenal päeval, E, 2007-03-26 kel
On Tue, Mar 27, 2007 at 11:08:44AM -0700, David Fetter wrote:
> On Sun, Mar 25, 2007 at 10:18:14PM -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > I've written up a patch intended to implement this on the
> > > non-pg_catalog tables and VIEWs, but while it builds, it doesn
On Tue, 2007-03-27 at 11:40 -0400, Andrew Dunstan wrote:
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl?sortby=name
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl?sortby=os
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl?sortby=compiler
Looks perfect. Many thanks.
--
Simon Riggs
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL. I've got
a practical proposal that looks like it can be completed in a few more
days work and fits very well with HOT UPDATEs.
This is likely to have beneficial p
+++
We'd love this feature as it would really help us write better test cases !
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
Sent: Tuesd
On Sun, Mar 25, 2007 at 10:18:14PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > I've written up a patch intended to implement this on the
> > non-pg_catalog tables and VIEWs, but while it builds, it doesn't
> > initdb. Enclosed are the patch and the error log.
> > Any hint
Magnus Hagander wrote:
> Would not at least some of these numbers be better presented through the
> stats collector, so they can be easily monitored?
>
> That goes along the line of my way way way away from finished attempt
> earlier, perhaps a combination of these two patches?
Yes.
Would not at least some of these numbers be better presented through the
stats collector, so they can be easily monitored?
That goes along the line of my way way way away from finished attempt
earlier, perhaps a combination of these two patches?
//Magnus
Bruce Momjian wrote:
> Is this patch rea
Where are we on this patch idea?
---
Koichi Suzuki wrote:
> Sorry for the late responce;
>
> Gzip can reduce the archive log size about one fourth. My point is
> that it can still be large enough.Removing physical lo
Bruce Momjian wrote:
Yes, yes. I would like to have used it when testing the MyProc->xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
Hear hear! I had trouble writing regression tests for the MVCC-
I am still unclear why sigres is better than a temporary file system. I
relize your patch is faster, but what is about your patch that makes it
faster.
And if we were going to add such capability, we would name it based on
what it does, rather than on a 'sigres' mode.
--
David Fetter <[EMAIL PROTECTED]> writes:
> On Mon, Mar 26, 2007 at 07:31:20PM -0400, Neil Conway wrote:
>> Can't we just remove the file outright? The last release of Ultrix
>> was in 1995.
> Sadly, in the US, at least, and so that file, absent sweeping changes
> in the law, will remain outside th
Joshua D. Drake wrote:
David Fetter wrote:
Sadly, in the US, at least, and so that file, absent sweeping changes
in the law, will remain outside the public domain until slightly after
the first human-crewed starship departs our solar system.
Hardly, we will have populated at least 3 solar s
David Fetter wrote:
On Mon, Mar 26, 2007 at 07:31:20PM -0400, Neil Conway wrote:
Bruce Momjian wrote:
FYI, I have received permission, below, to remove the Andrew Yu
copyright. Thanks.
Can't we just remove the file outright? The last release of Ultrix
was in 1995.
Sadly, in the US, at least
On Mon, Mar 26, 2007 at 07:31:20PM -0400, Neil Conway wrote:
> Bruce Momjian wrote:
> >FYI, I have received permission, below, to remove the Andrew Yu
> >copyright. Thanks.
>
> Can't we just remove the file outright? The last release of Ultrix
> was in 1995.
Sadly, in the US, at least, and so th
Is this patch ready?
---
Greg Smith wrote:
> I have a WIP patch that adds the main detail I have found I need to
> properly tune checkpoint and background writer activity. I think it's
> almost ready to submit (you can se
On Tue, Mar 27, 2007 at 05:43:53AM -0600, Michael Fuhr wrote:
> On Tue, Mar 27, 2007 at 07:33:08AM -0400, Andrew Dunstan wrote:
> > We can certainly provide a different view, or sort it by system
> > name,
>
> What about making the column headers clickable to control the sort
> order?
There's an
Simon Riggs wrote:
We can certainly provide a different view, or sort it by system name,
but I'm not sure that will actually show you what you want. If you want
to see the history on a particular system/branch, there is a separate
page for that - just click the system's name on the dashboard
Heikki Linnakangas wrote:
Here's what's happening:
1. Client 1 issues fsync (A)
2. Clients 2-5 write their commit record, and try to fsync, but they
have to wait for fsync (A) to finish.
It contains a graph that shows that the patch works very well for this
test case. It's not very good for
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This page is a dashboard. It shows the latest state of each build system
> on each branch during the last 30 days.
> The advantage to sorting it by snapshot is that you can quickly see when
> something broke a bunch of builds.
Yes --- I will be exceed
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> test=# CREATE TABLE test_in (field varchar(3));
> CREATE TABLE
> test=# CREATE INDEX idx_test_in ON test_in(field) WHERE field IN('1', '2');
> ERROR: functions in index predicate must be marked IMMUTABLE
Hmm. This is generating a coercion from varch
Yes, yes. I would like to have used it when testing the MyProc->xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
---
Gregory S
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
>> Er, what listen table?
> At least the list of which backends listen to which events should be
> also in shared mem.
No, the intent is specifically that there will be *no* such g
Ühel kenal päeval, E, 2007-03-26 kell 16:05, kirjutas Joris Dobbelsteen:
> Oracle has choosen to allow constraint enforcement by locking on the
> parent tuple. In contrast postgres has chosen (historically, see RI
> triggers) to fail on detecting conflicting newly inserted rows (the
> cross-check)
Would people be interested in this feature? There was some positive reaction
from users but I'm not sure how excited developers are about complicating the
logic in psql (which is already pretty tangled).
This code bitrotted severely when Tom added the cursor support to psql. I
don't mind redoing
Ühel kenal päeval, T, 2007-03-27 kell 16:13, kirjutas Hannu Krosing:
>
> How else would we know how many copies to make for each backend or when
> we can release the memory in case we make one copy ?
>
> > (see earlier discussion).
>
> could you post a link to archives ?
Sorry, found it now.
Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
>
> Hannu Krosing wrote:
> > So perhaps it Alvaros proposal can be rephrased thus:
> > "Why have the name on each message? The names are already stored in
> > listen table, just reuse numeric identifier pointing to item in that
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
and b) that there is broad agreement on the general design (i.e. to use a
circular buffer in shared memory, of configurable size, to hold the
outstanding message queue).
Would it spill out to disk and expand (and shr
On Tue, 2007-03-27 at 07:33 -0400, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > http://www.pgbuildfarm.org/cgi-bin/show_status.pl
> >
> > Could we sort the results by System, please? At least as an option.
> >
> > It's currently fairly hard to review the details to see whether a
> > particular
On Tue, Mar 27, 2007 at 07:33:08AM -0400, Andrew Dunstan wrote:
> We can certainly provide a different view, or sort it by system name,
What about making the column headers clickable to control the sort
order?
--
Michael Fuhr
---(end of broadcast)---
Simon Riggs wrote:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Could we sort the results by System, please? At least as an option.
It's currently fairly hard to review the details to see whether a
particular release level is supported/tested. The sort order changes
over time, which isn'
Hannu Krosing wrote:
Now that I think about it again, maybe we should NOT go for a
shared memory implementation after all, as we now have HOT updates and
thanks to the fact, that we have 1:1 correspondence between the backends
and
deleters in LISTEN/NOTIFY we can have much more exact DEAD-nes
Should these designations be more generic in case there are other uses
for enabling/disabling groups of triggers?
That would be fine with me, I just wasn't able to come up with any
sensible naming scheme other than replication related. Can you?
The best I could think of would be to create numb
Hannu Krosing wrote:
I find the feature very useful, and have even done some preliminary
design work for shared memory implementation, where each listener is
required to copy data to its own privat memory ASAP and notifier waits
in case there is not enough room in shared memory buffer.
Alas, I
Hannu Krosing wrote:
So perhaps it Alvaros proposal can be rephrased thus:
"Why have the name on each message? The names are already stored in
listen table, just reuse numeric identifier pointing to item in that
table. That gives you room for a lot more messages."
If there is no name in listen
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... But ISTM that means we just need to pick a few strategic spots
that will call CHECK_FOR_NOTIFICATIONS() even in the middle of a
transaction and store them locally.
Minor comment --- I don't believe in having a separate "
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Could we sort the results by System, please? At least as an option.
It's currently fairly hard to review the details to see whether a
particular release level is supported/tested. The sort order changes
over time, which isn't useful.
Build failur
Ühel kenal päeval, T, 2007-03-27 kell 11:17, kirjutas Hannu Krosing:
> Ühel kenal päeval, E, 2007-03-26 kell 11:30, kirjutas Andrew Dunstan:
> > This feature (ability to add a message payload to a NOTIFY) is on the
> > TODO list and I had undertaken to implement it. However, pressure of
> > other
Ühel kenal päeval, E, 2007-03-26 kell 11:30, kirjutas Andrew Dunstan:
> This feature (ability to add a message payload to a NOTIFY) is on the
> TODO list and I had undertaken to implement it. However, pressure of
> other work has conspired to make that difficult, and Abhijit Menon-Sen
> recently
On 3/26/07, Tom Lane <[EMAIL PROTECTED]> wrote:
It might be feasible to have RelationReloadClassinfo re-read the
pg_index row and apply only the updates for specific known-changeable
columns. The stuff it's worried about is the subsidiary data such
as support function fmgr lookup records, but
On 3/27/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I removed the advertising clause from all the BSD-copyrighted files from
Berkeley, namely all but */blf.*.
Their upstream is OpenBSD that still has same license.
NetBSD and FreeBSD have even worse versions with ssleay
license.
I think I need
66 matches
Mail list logo
