On May 26, 2004, at 12:47 AM, Neil Conway wrote:
I've applied the list rewrite patch to CVS HEAD. I've also sent a copy
of the patch I applied to the -patches list.
Nifty.
Do we have any numbers as to how much this will help things?
If not, would something like a pg_bench exercise the new code
Ingres is to be released as open source:
http://developers.slashdot.org/article.pl?sid=04/05/25/0043219mode=nestedtid=126tid=137tid=163tid=185tid=198
Like the article says, I wonder if these is any synergy between the
products. ie. Can we grab features from their codebase?
Chris
Patch applied. Thanks.
Backpatched to 7.4.X.
---
Matthew T. O'Connor wrote:
This weekend I am trying to fix up all known the pg_autovacuum issues
that should be resolved for 7.4.3. I am aware of only two issues: temp
Now that it looks like tablespaces will become a practical reality, I want
to suggest some changes in documented procedure and preferred setup. The
reason why I suggest these changes is to enlighten new PostgreSQL users to
the new features and, perhaps, make a more enterprise-familiar environment
[EMAIL PROTECTED] writes:
First, we keep the standard PostgreSQL directory the way it has always
been with template0, template1, pg_xlog, pg_clog, etc. in the same place.
We can refer to this as the system directory. This makes sense because
all the system level stuff is there. User databases
I have a table with about 16,000,000 rows in it.
When I do a:
SELECT * FROM table LIMIT 1;
it takes about 10 minutes (thats about how long it takes to do a full
sequential scan).
I had originally thought that there might be a large number of
wasted/retired tuples in the table so I vacuum
David Blasby wrote:
I have a table with about 16,000,000 rows in it.
When I do a:
SELECT * FROM table LIMIT 1;
it takes about 10 minutes (thats about how long it takes to do a full
sequential scan).
I had originally thought that there might be a large number of
wasted/retired tuples in the
Gaetano Mendola wrote:
David Blasby wrote:
I have a table with about 16,000,000 rows in it.
When I do a:
SELECT * FROM table LIMIT 1;
it takes about 10 minutes (thats about how long it takes to do a full
sequential scan).
I had originally thought that there might be a large number of
Hackers,
Ok, I've finally coded solutions to most problems regarding nested
transactions. This means:
- reversing for the lock manager, catcache, relcache, buffer manager,
asynchronous notifies, storage manager.
- transaction block state support, including appropiate XLog recording
-
David Blasby [EMAIL PROTECTED] writes:
I have a table with about 16,000,000 rows in it.
When I do a:
SELECT * FROM table LIMIT 1;
it takes about 10 minutes (thats about how long it takes to do a full
sequential scan).
The only explanation that comes to mind is huge amounts of dead space
David Blasby [EMAIL PROTECTED] writes:
I just did another vacuum analyse on the table:
Ah, here we go:
INFO: csn_edges: found 0 removable, 16289929 nonremovable row
versions in 2783986 pages
That works out to just under 6 rows per 8K page, which wouldn't be too
bad if the rows are 1K wide
Tom Lane wrote:
INFO: csn_edges: found 0 removable, 16289929 nonremovable row
versions in 2783986 pages
That works out to just under 6 rows per 8K page, which wouldn't be too
bad if the rows are 1K wide on average, but are they? (You might want
to run contrib/pgstattuple to get some exact
[EMAIL PROTECTED] writes:
First, we keep the standard PostgreSQL directory the way it has always
been with template0, template1, pg_xlog, pg_clog, etc. in the same
place.
We can refer to this as the system directory. This makes sense because
all the system level stuff is there. User
David Blasby [EMAIL PROTECTED] writes:
I just did another vacuum analyse on the table:
Ah, here we go:
INFO: csn_edges: found 0 removable, 16289929 nonremovable row
versions in 2783986 pages
That works out to just under 6 rows per 8K page, which wouldn't be too
bad if the rows are 1K
On Wed, 26 May 2004, Alvaro Herrera wrote:
I'm missing one item: deferred triggers. The problem with this is that
the deftrig queue is not implemented using normal Lists, so there's no
efficient way to reassign to the parent when the subtransaction commits.
Also I'm not sure what should
It wouldn't; you'd need vacuum full to collapse out the dead space.
You could also try CLUSTER which is faster than VACUUM FULL when most
of the data has to be moved anyway. (Some days I think we should dump
VACUUM FULL, because it's optimized for a case that's no longer very
interesting...)
Out
BTW: Is there a public spec on what will be tablespace compatible and how?
For instance: will is be possible to create a table on a separate
tablespace than the DB? Will it be possible to create an index on a
separate tablespace than the table?
(Since Gavin hasn't replied yet)
1. There are two
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It wouldn't; you'd need vacuum full to collapse out the dead space.
You could also try CLUSTER which is faster than VACUUM FULL when most
of the data has to be moved anyway. (Some days I think we should dump
VACUUM FULL, because it's optimized
David Blasby [EMAIL PROTECTED] writes:
I have another copy of this table in another database - vacuum analyse
verbose says its only 1,500,000 pages (vs 2,800,000).
Hmm ... this is consistent with the idea that you did an UPDATE
affecting every row of the table. That would generate N new rows
On May 26, 2004, at 7:14 PM, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
First, we keep the standard PostgreSQL directory the way it has
always
been with template0, template1, pg_xlog, pg_clog, etc. in the same
place.
We can refer to this as the system directory. This makes sense
because
Tom Lane wrote:
of dead tuples followed by a lot of pages worth of live tuples. Plain
VACUUM cannot do much to fix this since it doesn't move rows around.
VACUUM FULL will fix it, but its index-update overhead is high enough
that CLUSTER is a better deal.
Tom: I was interested in performance
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
But what about kerberos: I'm a bit reluctant to add a forth mutex: what
if kerberos calls gethostbyname or getpwuid internally?
Wouldn't help anyway, if some other part of the app also calls kerberos.
I think we should just state
On Wed, May 26, 2004 at 04:35:52PM -0700, Stephan Szabo wrote:
On Wed, 26 May 2004, Alvaro Herrera wrote:
I'm missing one item: deferred triggers. The problem with this is that
the deftrig queue is not implemented using normal Lists, so there's no
efficient way to reassign to the parent
23 matches
Mail list logo
