Bruce Momjian <[EMAIL PROTECTED]> writes:
> By doing REINDEX always, we eliminate some folks are are happy
> doing VACUUM FULL at night, because very few tuples are expired.
But if they have very few tuples expired, why do they need VACUUM FULL?
Seems to me that VACUUM FULL should be designed to c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think that's not happening, conditionally or otherwise. The atomicity
>> problems alone are sufficient reason why not, even before you look at
>> the performance issues.
> What are the atomicity problems of adding a create/expire xi
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Improve speed of building of constraints during restore
> Did we get consensus on what to do with this,
Not really, it was still up in the air I thought. However, the
discussion will become moot if we don't have an implementation
of the faster-checkin
On Sun, 5 Oct 2003, Bruce Momjian wrote:
> Improve speed of building of constraints during restore
Did we get consensus on what to do with this, whether we're doing
only the superuser option to not check, only speeding up fk constraint
checks by using a statement instead of the repeated calls, b
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
---
Fix REVOKE ALL ON FUNCTION error when removing owner permissions
Improve speed of building of constraints d
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> No. You'd be better off using REINDEX for that, I think.
>
> > I guess my point is that if you forget to run regular vacuum for a
> > month, then realize the problem, you can just do a VACUUM FULL and the
> > hea
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > The point I was trying to make was that faster count(*)'s is just a side
> > effect. If we could (conditionally) keep visibility info in indexes,
>
> I think that's not happening, conditionally or otherwise. The atomicity
> problems
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No. You'd be better off using REINDEX for that, I think.
> I guess my point is that if you forget to run regular vacuum for a
> month, then realize the problem, you can just do a VACUUM FULL and the
> heap is back to a perfect state a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
>> No. You'd be better off using REINDEX for that, I think. IIRC we have
>> speculated about making VAC FULL fix the indexes via REINDEX rather than
>> indexbulkdelete.
> I can't agree with tha
On Sat, Oct 04, 2003 at 11:17:09PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Do we move empty index pages to the end before truncation during vacuum
> > > full?
> >
> > No. You'd be better off using REINDEX for that, I think. IIRC we have
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we move empty index pages to the end before truncation during vacuum
> > full?
>
> No. You'd be better off using REINDEX for that, I think. IIRC we have
> speculated about making VAC FULL fix the indexes via REINDEX rather than
>
On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we move empty index pages to the end before truncation during vacuum
> > full?
>
> No. You'd be better off using REINDEX for that, I think. IIRC we have
> speculated about making VAC FULL
Excellent idea.
Here's the URL: http://www.dunslane.net/~andrew/Initdb_In_C.html
cheers
andrew
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I now have a C implementation of initdb, ...
> > There's a little work still to go
Anyone see a better way?
Switch everything to mmap and pthreads and dump all this antiquated SysV IPC
and semaphore junk? *DUCK*
You are a brave soult. I salute you.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC
Postgresql support, p
Greg Stark <[EMAIL PROTECTED]> writes:
> So I'm a bit confused about the term "Clustering". It seems Postgres uses it
> to mean simply ordering the tuple storage within an otherwise normal table.
> However in other databases it seems to mean something more complex.
My take is that "clustering" me
Greg Stark <[EMAIL PROTECTED]> writes:
> Perhaps the shared_buffers should only be set to 50% of the maximum size
> probed?
I think it's reasonable to expect the DBA to make any adjustments needed
for changes in environment. Partly this is because I don't see any
defensible way to do otherwise --
James Rogers <[EMAIL PROTECTED]> writes:
> On 10/2/03 11:34 PM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
> >
> > What I actually thought I was describing is how CLUSTER should work in a
> > postgres flavour of MVCC storage ;). Not the CLUSTER command, but the
> > whole feature.
>
>
> Yeah, I
On 10/4/03 2:00 AM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
>
> If the WHERE clause could use the same index (or any index with
> visibility info) then there would be no need for "walking through the
> tuples" in data relation.
>
> the typical usecase cited on [HACKERS] was time series data, w
Hannu Krosing <[EMAIL PROTECTED]> writes:
> The point I was trying to make was that faster count(*)'s is just a side
> effect. If we could (conditionally) keep visibility info in indexes,
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are sufficient reason
Tom Lane <[EMAIL PROTECTED]> writes:
> (BTW, on my OS X machine, with out-of-the-box configuration, initdb
> selects shared_buffers 400 and max_connections 20. I'm guessing that
> you had either a nondefault shared memory limit, or some other process
> using shared memory.)
This points out anot
Tom Lane kirjutas L, 04.10.2003 kell 19:07:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
> >> A while back I outlined how this would have to be done, and for it to
> >> be done efficiently, it would be anything BUT simple.
>
> > Could this
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I now have a C implementation of initdb, ...
> There's a little work still to go (see below), but I'd appreciate some
> eyeballs on it to see if I have made any major booboos, or could have
> done things better. What's the best way to proceed?
Put it
On 10/2/03 11:34 PM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
> James Rogers kirjutas N, 02.10.2003 kell 23:44:
>> Not exactly. What you are describing is more akin to partitioning or
>> hash-organized tables i.e. sorting insert/update tuples to various pages
>> according to some hash function.
>
I said:
> Hm. The parallel regression tests require at least 20. I deliberately
> allowed initdb to select values as small as 10 on the theory that
> installing and not being able to run the parallel regression tests is
> better than not installing at all.
Actually, after trying to reproduce the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have added this to the 7.4 open items list:
> Fix pg_dump of CREATE TABLE test (col1 BOOLEAN CONSTRAINT test
> CHECK (col1))
Fixed now.
regards, tom lane
---(end of broadcast)--
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> The following is still a problem in current cvs (as of 2 hours ago).
Not any more ;-)
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to cho
I have added this to the 7.4 open items list:
Fix pg_dump of CREATE TABLE test (col1 BOOLEAN CONSTRAINT test
CHECK (col1))
---
Bruno Wolff III wrote:
> The following is still a problem in current cvs (as of
Darko Prenosil writes:
> I see that hr translation for libpq is applied, but not that one for
> backend that I send few days ago.
> Is there any problem with it ?
It might have gotten caught in my mail filters. I've taken it from the
archives and applied it now.
--
Peter Eisentraut [EMAI
When grilled further on (Sat, 4 Oct 2003 12:50:27 -0500),
Bruno Wolff III <[EMAIL PROTECTED]> confessed:
> The following is still a problem in current cvs (as of 2 hours ago).
> Normally I wouldn't bug people about this again this soon, but with talk of
> a release candidate next week I wanted to
The following is still a problem in current cvs (as of 2 hours ago).
Normally I wouldn't bug people about this again this soon, but with talk of
a release candidate next week I wanted to make sure that it wasn't forgotten.
On Sun, Sep 28, 2003 at 20:14:03 -0500,
Bruno Wolff III <[EMAIL PROTECTED
Rod Taylor <[EMAIL PROTECTED]> writes:
>> Hm. The parallel regression tests require at least 20. I deliberately
>> allowed initdb to select values as small as 10 on the theory that
>> installing and not being able to run the parallel regression tests is
>> better than not installing at all.
> An
> Hm. The parallel regression tests require at least 20. I deliberately
> allowed initdb to select values as small as 10 on the theory that
> installing and not being able to run the parallel regression tests is
> better than not installing at all. Does anyone want to argue the
> opposite? Perh
Adam Witney <[EMAIL PROTECTED]> writes:
> On 4/10/03 5:16 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> What did initdb set your max_connections to?
> From src/test/regress/log/initdb.log
> selecting default max_connections... 10
Hm. The parallel regression tests require at least 20. I deliberat
On Fri, Oct 03, 2003 at 08:57:49 -0500,
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> I get the error message below when trying to 'make' current cvs:
> gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic
> -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils
> -
On 4/10/03 5:16 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> Many of the regression tests are failing on my OSX 10.2.6 machine. I have
>> put the regression.diffs file here
>> http://bugs.sghms.ac.uk/downloads/regression.diffs
>
> Seems to be all
>
> ! p
Adam Witney <[EMAIL PROTECTED]> writes:
> Many of the regression tests are failing on my OSX 10.2.6 machine. I have
> put the regression.diffs file here
> http://bugs.sghms.ac.uk/downloads/regression.diffs
Seems to be all
! psql: FATAL: sorry, too many clients already
What did initdb set your m
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
>> A while back I outlined how this would have to be done, and for it to
>> be done efficiently, it would be anything BUT simple.
> Could this be made a TODO item, perhaps with your attack plan.
I
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Regarding the dollar-quoting discussions -
> Will we be able to write the above query as
> SELECT smth. FROM tbl WHERE WHERE situation LIKE $$%\\%$$;
> in 7.4 or is \ still special there ?
We were discussing that for 7.5 not 7.4. But yeah, it would w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we move empty index pages to the end before truncation during vacuum
> full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
indexbulkdelete.
The world rejoiced as [EMAIL PROTECTED] (Mike Mascari) wrote:
> It's a very provocative read. At a minimum, one can learn what to
> avoid with SQL. The language looks neat on paper. Perhaps one day
> someone will provide an open source implementation. One could envision
> a "D" project along the sa
Hi,
Many of the regression tests are failing on my OSX 10.2.6 machine. I have
put the regression.diffs file here
http://bugs.sghms.ac.uk/downloads/regression.diffs
Has this been seen before?
Thanks
adam
> Check her over and let me know if there are any problems ... will do a
> full general
but this will be in 7.5, not 7.4, won't it?
Andrew Dunstan wrote:
- Original Message -
From: "Hannu Krosing" <[EMAIL PROTECTED]>
Regarding the dollar-quoting discussions -
Will we be able to write the above query as
SELECT smth. FROM tbl WHERE WHERE situation LIKE $$%\\%$$;
Y
- Original Message -
From: "Hannu Krosing" <[EMAIL PROTECTED]>
>
> Regarding the dollar-quoting discussions -
>
> Will we be able to write the above query as
>
> SELECT smth. FROM tbl WHERE WHERE situation LIKE $$%\\%$$;
>
Yes, as I understand it (as long as you remove the one of the WH
regression=# UPDATE foo SET f2=now() WHERE f1=1;
ERROR: deadlock detected
DETAIL: Process 18122 waits for AccessExclusiveLock on relation 154635 of database
17139; blocked by process 18133.
Process 18133 waits for ShareLock on transaction 6330; blocked by process 18122.
The trouble here is that
Thanks - that's what I ended up doing. Hooray for CLUSTER indexes and
constraints in phpPgAdmin CVS now!
Chris
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
If someone could help me with this, it would be cool. How do I query
the catalogs to find the underlying index f
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
> [EMAIL PROTECTED] (Jean-Luc Lachance) writes:
> > That's one of the draw back of MVCC.
> > I once suggested that the transaction number and other house keeping
> > info be included in the index, but was told to forget it...
> > It would solv
I see that hr translation for libpq is applied, but not that one for
backend that I send few days ago.
Is there any problem with it ?
Regards !
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postg
Tom Lane kirjutas R, 03.10.2003 kell 18:34:
> Michael Brusser <[EMAIL PROTECTED]> writes:
> > But when I doubled the number of backslashes:
> > SELECT smth. FROM tbl WHERE situation LIKE '%%';
> > - it actually worked fine.
>
> Backslash is special to both the string-literal parser and the
Mike Mascari kirjutas L, 04.10.2003 kell 06:32:
>
> 2) The query language should be computationally complete. The user
> should be able to author complete applications in the language, rather
> than the language being a sublanguage.
To me it seems like requiring that one should be able to author
49 matches
Mail list logo
