Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Regards
J Mageshwaran
** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to
Sify Limited and is intended for use only by the individual or entity to
Then you cannot run any queries that extend the size of
your relations
(for example INSERT, UPDATE etc.). Unless you drop your tables or
DELETE something
Interesting. Well my two cents is don't go any deeper than database.
I.e; don't try and track to the individual relation.
I
On Thu, 2007-03-01 at 11:00 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
VACUUM's current behaviour is to take blocks it has touched and place
them on the head of the freelist, allowing them to be reused.
No, it puts them at the tail of the freelist.
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I've disabled packed varlenas for user-defined data types and find tsearch2
and _int still fail. tsearch2 requires the small patch attached. _int seems
to
be unrelated.
As of when? I committed fixes earlier
Mageshwaran wrote:
Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Here are some ideas:
lose the idiotic, pointless and inaccurate email addendum, especially
the ads for bollywood etc.
do some research yourself, especially by reading the
Under normal operations, shutting down the database does a
checkpoint, right? So unless you're in recovery mode, there's
no additional cost.
And I can't think of any reason you'd need to see any pages
before the last checkpoint (unless you don't trust your disk
and just want to check
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
Maybe a suitable replacement for full-page would be to sync the first WAL
record for a page change before writing the buffer
We *always* sync WAL records for page changes before writing the buffer for
the page.
--
Gregory Stark
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
cannot skip a value in the sequence, the strict
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
cannot skip a value in the
Zoltan Boszormenyi írta:
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
BenchmarkSQL is open source, but, I don't think anyone has published version
5.2 yet on pgFoundry. Amongst other goodies, version 5.2 allows for the
running of Java based tpcC and/or tpcB like benchmarks from the command line
or the cutsie gui. We've also added consistency checks to the end
Zoltan Boszormenyi wrote:
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
Use case for VACUUM FULL is very low these days. VACUUM does the most
important part of what VACUUM FULL offers, yet does it concurrently
rather than with a full table lock. VACUUM FULL also
- has very long execution time
- generates lots of WAL traffic
- uses lots of memory while it runs
- isn't
Florian G. Pflug írta:
Yes, of course you can prevent gaps by just filling them
with garbage/invalid records of whatever. But I don't see
why this is usefull - either you want, say, your invoice
number to be continuous because it's required by law - or
you don't. But if the law required your
Hi
Just to add an question to it.. do we have a felixbitily to run this
xlogdump or xlogviewer on windows installation of Postgres. Also how do we
run these utilities with the existing postgres server running on linux box.
thanks
Vishal
From: Jonah H. Harris [EMAIL PROTECTED]
To:
On Thu, 2007-03-01 at 13:02, Simon Riggs wrote:
I would like to introduce the concept of utility transactions. This is
any transaction that touches only one table in a transaction and is not
returning or modifying data. All utility transactions wait until they
are older than all non-utility
Ühel kenal päeval, N, 2007-03-01 kell 12:02, kirjutas Simon Riggs:
Use case for VACUUM FULL is very low these days. VACUUM does the most
important part of what VACUUM FULL offers, yet does it concurrently
rather than with a full table lock. VACUUM FULL also
- has very long execution time
-
Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:
If we can trust FSM, the whole process just becomes the backward scan
and null updates until the null update does not move tuple to a lower
page. Also, for the duration of COMPACT TABLE the updated tuple should
always be
On Thu, 2007-03-01 at 13:21 +0100, Csaba Nagy wrote:
On Thu, 2007-03-01 at 13:02, Simon Riggs wrote:
I would like to introduce the concept of utility transactions. This is
any transaction that touches only one table in a transaction and is not
returning or modifying data. All utility
On Thu, 2007-03-01 at 13:56, Simon Riggs wrote:
Wouldn't this be deadlock prone ? What if a non-utility transaction
(which could even be started before the vacuum full) blocks on the table
being vacuumed, then if the vacuum wants to wait until all non-utility
transactions finish will
On Thu, 2007-03-01 at 14:32 +0200, Hannu Krosing wrote:
Ühel kenal päeval, N, 2007-03-01 kell 12:02, kirjutas Simon Riggs:
Use case for VACUUM FULL is very low these days. VACUUM does the most
important part of what VACUUM FULL offers, yet does it concurrently
rather than with a full table
On Thu, 2007-03-01 at 14:42 +0200, Hannu Krosing wrote:
Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:
If we can trust FSM, the whole process just becomes the backward scan
and null updates until the null update does not move tuple to a lower
page. Also, for the
Maybe a suitable replacement for full-page would be to sync the
first
WAL record for a page change before writing the buffer
We *always* sync WAL records for page changes before writing
the buffer for the page.
Um, is that so ? And how is that done ? (e.g. bgwriter would need to
wait
I admit that the implementation is much complex, but I can
not see any big problems to save the dead tuples out and read
it in again(like two phase commit does). Why do we need to
hold the lock and transaction? We can open the lock and
abandon the transaction ID, vacuum can take the lock
On 2/26/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 2/23/07, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On friday we upgraded a critical backend server to postgresql 8.2
running on fedora core 4.
Umm ... why that particular choice of OS? Red Hat dropped
Andrew Dunstan wrote:
Mageshwaran wrote:
Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Here are some ideas:
Tsk, Andrew.
Replication in PostgreSQL is usually served via Point in Time recovery,
Slony (http://www.slony.info) or Mammoth
-- start the VACUUM from the first non-filled block
So if we do this, we wouldn't need to worry about HOT tuples
at all, nor would we need to wait until all transactions are gone.
You need to wait until you are allowed to truncate if you want
concurrency.
Or a concurrent scan
Ühel kenal päeval, N, 2007-03-01 kell 13:14, kirjutas Simon Riggs:
On Thu, 2007-03-01 at 14:42 +0200, Hannu Krosing wrote:
Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:
If we can trust FSM, the whole process just becomes the backward scan
and null updates until
On Thu, 2007-03-01 at 14:35 +0100, Zeugswetter Andreas ADI SD wrote:
-- start the VACUUM from the first non-filled block
So if we do this, we wouldn't need to worry about HOT tuples
at all, nor would we need to wait until all transactions are gone.
You need to wait until
On Thu, Mar 01, 2007 at 08:32:57AM -0500, Merlin Moncure wrote:
Following an emergency downgrade back to 8.1, the kernel panics went
away. Note that I don't believe for a second that the database was
the root cause here...research suggest that the problem is due to some
type of bug in the
Hi All,
Here are some preliminary numbers with the HOT 4.0 patch that I sent
out earlier today. These are only indicative results and should not be
used to judge the performance of HOT in general. I have intentionally
used the setup favorable to HOT. The goal here is to point out the best
Zoltan Boszormenyi írta:
The cost I am thinking now is an extra heap_update()
after heap_insert() without generating the identity value
and inserting index tuples to indexes that doesn't
contain the identity column.
And as far as I tested the current state, there is no cost
if you don't use
One imho important (not necessarily mandatory) aspect of HOT
is, that it does parts of what vacuum would usually do.
Thus:
1. resume, load ctid list
2. continue filling ctid list
3. remove index tuples for these ctids (* problem *)
You have just removed index entries
Zeugswetter Andreas ADI SD wrote:
Maybe a suitable replacement for full-page would be to sync the
first
WAL record for a page change before writing the buffer
We *always* sync WAL records for page changes before writing
the buffer for the page.
Um, is that so ? And how is that done ? (e.g.
Hi All,
Please see the version 4.0 of HOT WIP patch posted on pgsql-patches.
I am having some trouble since afternoon posting the patch, tried
multiple times. So not sure if has made to -patches yet. If doesn't get
through on -patches this time also I would retry after few hours again.
-- start the VACUUM from the first non-filled block
So if we do this, we wouldn't need to worry about HOT tuples at
all,
nor would we need to wait until all transactions are gone.
You need to wait until you are allowed to truncate if you want
concurrency.
Or a
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
We are happy to provide that. If and when it comes to the final patch being
accepted, we can send a copyright waiver mail which will put our source code
contribution under the BSD license.
This approach is not practically workable
Hello,
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Florian G. Pflug, on a post (
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00081.php )
suggested that there were no way to let the old entry until the command
commit.
I would like Cluster to create a
Hi
I've updated (or rather rewritten) my proposal for implementing
read-onyl queries on PITR slaves as a Summer of Code 2007 project.
I've added are more details description of how I plan implement
a read-only mode suitable for PITR slaves, and put in a few
possible enhancements to the Big,
Ühel kenal päeval, N, 2007-03-01 kell 15:03, kirjutas Zeugswetter
Andreas ADI SD:
-- start the VACUUM from the first non-filled block
So if we do this, we wouldn't need to worry about HOT tuples at
all,
nor would we need to wait until all transactions are gone.
On Wed, Feb 28, 2007 at 10:14:24PM +, Heikki Linnakangas wrote:
cache instead. In the index scan phase, it's randomly accessed, but if
the table is clustered, it's in fact not completely random access. In
the 2nd vacuum pass, the array is scanned sequentially again. I'm not
Only if
Jim C. Nasby wrote:
On Wed, Feb 28, 2007 at 10:14:24PM +, Heikki Linnakangas wrote:
cache instead. In the index scan phase, it's randomly accessed, but if
the table is clustered, it's in fact not completely random access. In
the 2nd vacuum pass, the array is scanned sequentially again. I'm
On 3/1/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
accounts 157895 (initial size) 49284 (increase)
accounts_pkey 19709 (initial size) 19705 (increase)
Just to clarify, the relation size and increase is in number of blocks.
Thanks,
Pavan
--
EnterpriseDB
On Wed, Feb 28, 2007 at 12:16:10PM -0500, Bruce Momjian wrote:
background writer, and I think after a server crash, all pages would
have to be read and checked. The good news is that both of these are
Would they? If you're doing recovery you'd have to read all pages
dirtied since the last
Jonathan Scher [EMAIL PROTECTED] writes:
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Because when it drops the old copy of the table there had better not be
any concurrent readers.
regards, tom lane
---(end of
accounts 157895 (initial size) 49284 (increase)
accounts_pkey 19709 (initial size) 19705 (increase)
Just to clarify, the relation size and increase is in number
of blocks.
The numbers are quite impressive :-) Have you removed the selects on
accounts too ?
Seems
On Wed, Feb 28, 2007 at 04:10:09PM +0900, ITAGAKI Takahiro wrote:
Jim C. Nasby [EMAIL PROTECTED] wrote:
At some point it might make sense to convert the FSM into a bitmap; that
way everything just scales with database size.
In the meantime, I'm not sure if it makes sense to tie the FSM
This means that
VACUUM FULL mytable;
would translate to:
VACUUM mytable; -- make free space
COMPACT mytable; -- move tuples in a bunch of small transactions
-- might have a GUC for max trx length
VACUUM mytable; -- free the tuples at the end and give space back to
Hello,
I have a single Athlon 2.3MHz. Then I bought a Netfinity 7600 with quad
Xeon 700MHz (for EUR 151 on Ebay, 2gb RAM included). I worked over my
application to run queries in parallel. I got a speedup from 13:37 min
(on the AMD) to 4:01 min (on the IBM). With this email I am suggesting
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
However, I get warning messages like:
WARNING: detected write past chunk end in ExecutorState 0xaaff68
How can I prevent them?
Find the memory-clobbering bug in your patch.
regards, tom lane
---(end
On 3/1/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
Hi All,
Here are some preliminary numbers with the HOT 4.0 patch that I sent
out earlier today. These are only indicative results and should not be
used to judge the performance of HOT in general. I have intentionally
used the setup favorable
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
However, I get warning messages like:
WARNING: detected write past chunk end in ExecutorState 0xaaff68
How can I prevent them?
Find the memory-clobbering bug in your patch.
regards, tom lane
Merlin Moncure wrote:
On 3/1/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
seems pretty solid except for one possible problem...at one point when
I dropped then later added the index on 'abalance', I got spammed
'WARNING: found a HOT-updated tuple' from psql prompt.
Thats intentional. We
Tom Lane a écrit :
Jonathan Scher [EMAIL PROTECTED] writes:
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Because when it drops the old copy of the table there had better not be
any concurrent readers.
regards, tom lane
Then,
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during
vacuum.
Not
On Thu, Mar 01, 2007 at 06:23:37PM +0100, Jonathan Scher wrote:
Because when it drops the old copy of the table there had better not be
any concurrent readers.
Then, is it possible to take a share update exclusive lock until the new
table is ready, then an access exclusive one only in order
On Wednesday 28 February 2007 14:31, Joshua D. Drake wrote:
Joshua D. Drake wrote:
Darcy Buskermolen wrote:
I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats
collector on an 8.2.3 box investigation has lead me to belive that the
stats file is written a lot more often
All,
Well, there were 30+ posts on the Google SoC thread. However, at the end
of it only Robert Treat, Dave Page, Mark Wong, and Josh Drake volunteered
to be mentors. Note that there's not *one* core-backend-code-committer in
that list.
We really, really, really need a couple of core-code
On Thu, 2007-03-01 at 22:35 +0530, Pavan Deolasee wrote:
Merlin Moncure wrote:
On 3/1/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
seems pretty solid except for one possible problem...at one point when
I dropped then later added the index on 'abalance', I got spammed
'WARNING:
Darcy Buskermolen [EMAIL PROTECTED] writes:
I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats
collector on an 8.2.3 box investigation has lead me to belive that the
stats file is written a lot more often that once every 500ms the
following shows this behavior.
Looks like
Josh Berkus wrote:
All,
Well, there were 30+ posts on the Google SoC thread. However, at the end
of it only Robert Treat, Dave Page, Mark Wong, and Josh Drake volunteered
to be mentors. Note that there's not *one* core-backend-code-committer in
that list.
We really, really, really need a
Andrew,
I told you I would and offered some suggestions ... last time I looked I
still had commit privs ...
Sorry, I must have missed that. On IRC?
Anyway, thank you and looking forward to it!
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of
Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats
collector on an 8.2.3 box investigation has lead me to belive that the
stats file is written a lot more often that once every 500ms the
following shows this
Andrew Dunstan [EMAIL PROTECTED] writes:
Good catch. I am also a bit dubious about this code:
input_fd.fd = pgStatSock;
input_fd.events = POLLIN | POLLERR;
input_fd.revents = 0;
Hm. The Single Unix Spec saith that POLLERR is ignored in the events
field, but it is not
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Good catch. I am also a bit dubious about this code:
input_fd.fd = pgStatSock;
input_fd.events = POLLIN | POLLERR;
input_fd.revents = 0;
Hm. The Single Unix Spec saith that POLLERR is ignored
On Wed, Feb 28, 2007 at 02:29:52PM -0800, Joshua D. Drake wrote:
I don't know, but in my opinion, I don't see anything bad in requiring
dropping the data if the quota is full. That's what usually occurs in
the case of normal filesystem quota... If you don't have a space there,
you cannot
Andrew Dunstan [EMAIL PROTECTED] writes:
This might all be OK - I just noticed it as I was looking at the
problem, so I though I'd mention it.
I'm inclined to leave that code alone unless someone can point to a
platform where setting POLLERR in events actually causes a problem.
The pgstat code
Hi!
I would like to suggest that we retire some of the old Visual C++ build
infrastructure. Specifically, all the makefiles for VC++ 6.0 *except* libpq.
There is a point for keeping libpq - if you want to build a static
version, it's easier if you can use the same version. And it's also
required
On Wed, 2007-02-28 at 12:56 -0500, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
Per user AND per database (as Tom noted). But I dont see what's odd in
it... It exists in Oracle, and I need quotas in the project on which I'm
working. And I remember user requests for quotas
Jeff Davis [EMAIL PROTECTED] writes:
If we allowed an admin to revoke CREATE from the pg_default tablespace,
then anyone who needed that feature could limit people to their own
tablespace (at which point it's the filesystem's job to limit their
usage). Is there some reason that we can't do
Jeff Davis wrote:
If we allowed an admin to revoke CREATE from the pg_default tablespace,
then anyone who needed that feature could limit people to their own
tablespace (at which point it's the filesystem's job to limit their
usage). Is there some reason that we can't do this now?
Andrew Dunstan wrote:
Jeff Davis wrote:
If we allowed an admin to revoke CREATE from the pg_default tablespace,
then anyone who needed that feature could limit people to their own
tablespace (at which point it's the filesystem's job to limit their
usage). Is there some reason that we can't
Joshua D. Drake [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Hitting a file system quota limit is likely to bring you down pretty
hard, isn't it?
Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem, it won't
stop or corrupt your database.
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Hitting a file system quota limit is likely to bring you down pretty
hard, isn't it?
Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem, it
On Thu, 2007-03-01 at 14:13 -0800, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Jeff Davis wrote:
If we allowed an admin to revoke CREATE from the pg_default tablespace,
then anyone who needed that feature could limit people to their own
tablespace (at which point it's the filesystem's
Jeff Davis [EMAIL PROTECTED] writes:
Is it possible to make the database safe in this case? I can see why it
would be difficult to handle pg_xlog filling up (or for that matter
pg_log), but couldn't any other area be turned into just a simple ERROR?
It is --- Josh is mistaken about the
Hi.
Yeah, as for me, it is already mutual agreement.:-)
Everyone will be able to use it easily. It is important in the meaning that avoids
useless confusion. Moreover, the DEBUG function of VS2005 is very excellent.
I think great evolution of it. Thanks!!
Regards,
Hiroshi Saito
I would
On Thu, 2007-03-01 at 17:53 -0500, Tom Lane wrote:
The real problem though is whether you can get anything much done if up
against a hard limit; especially if that limit also affects the system
catalogs. Remember that UPDATE requires the ability to insert new tuple
versions, so there are a
On Fri, 2 Mar 2007 01:20, Simon Riggs wrote:
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
Hi Simon,
We are happy to provide that. If and when it comes to the final patch
being accepted, we can send a copyright waiver mail which will put our
source code contribution under the
So it seems like we already have a solution to quotas at the database
level.
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in one
Sergey E. Koposov [EMAIL PROTECTED] writes:
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in one
directory. And since all the PG
On Thu, 1 Mar 2007, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in one
On Fri, 2007-03-02 at 03:31 +0300, Sergey E. Koposov wrote:
So it seems like we already have a solution to quotas at the database
level.
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific
On Thu, Mar 01, 2007 at 04:54:44PM +0200, Hannu Krosing wrote:
I was not suggesting that we remove visible rows through truncation.
Sure, unless you suggest to not truncate during this vacuum run ?
But we are talking about vacuum full, so truncation is essential.
It was suggested to
On Thu, Mar 01, 2007 at 01:05:28PM +, Simon Riggs wrote:
ISTM a radical approach is needed, so I'm very open to discussion about
this and how we cope.
If we break down the main thoughts into a few parts:
1. would like a way to CLUSTER/VACUUM FULL where we don't have to move
all of the
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, I'm not sure whether 2.5.4 will choke on unrecognized %option
commands --- if it has to be conditional on version it'll be a PITA.
%option noyyget_in
causes flex 2.5.4a to barf:
On closer investigation, flex does contain
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: array.sgml
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: array.sgml
Tatsuo Ishii [EMAIL PROTECTED] writes:
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Done.
Also please do not commit broken sgml files without trying to compile
them.
Some committers are using DocBook installations that
Tatsuo Ishii [EMAIL PROTECTED] writes:
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Done.
Thanks.
Also please do not commit broken sgml files without trying to compile
them.
Some committers are using DocBook
Hi Gavin,
Thanks for your comments.
I shall set up the ctids list to be stored in memory initially and dump to a
temp file if needed.
Regards,
John Bartlett
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin Sherry
Sent: Wednesday, 28 February 2007
Zeugswetter Andreas ADI SD wrote:
accounts 157895 (initial size) 49284 (increase)
accounts_pkey 19709 (initial size) 19705 (increase)
Just to clarify, the relation size and increase is in number
of blocks.
The numbers are quite impressive :-) Have you removed the
Postgres User [EMAIL PROTECTED] writes:
On 3/1/07, Tom Lane [EMAIL PROTECTED] wrote:
Postgres User [EMAIL PROTECTED] writes:
before opening cursor ref_entry = 'c_entry';
after looping thru cursor MOVE Backward All In c_entry;
You have to use EXECUTE for the latter.
I had tried
Just for curiosity, I would like to ask you why you need to modify
pgbench. pgbench can accept custom SQL scripts...
P.S. HOT seems to be one of the greatest enhancements since PostgreSQL
was born!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Hi All,
Here are some preliminary numbers with the HOT 4.0
On several occasions I have wanted to input integers in hexadecimal rather
than in decimal in PostgreSQL. I notice that there is a to_hex function,
but there is not (AFAIK) a way to provide an integer in hexadecimal.
I have written a pure-sql implementation of some functions to input
integers in
Jeremy Drake [EMAIL PROTECTED] writes:
On several occasions I have wanted to input integers in hexadecimal rather
than in decimal in PostgreSQL. I notice that there is a to_hex function,
but there is not (AFAIK) a way to provide an integer in hexadecimal.
regression=# select x'abcd'::int;
96 matches
Mail list logo
