On Wed, 26 May 2004, Tom Lane wrote:
if you have to do an UPDATE that affects every row of a large table
UPDATE tab SET col = col + 1
which leaves you with N live rows, N dead rows, and lots of pain to get
back down to a less-than-twice-normal-size table. (Traditional way is
On Thu, 27 May 2004, Alvaro Herrera wrote:
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
On Wed, 2004-02-11 at 16:36, [EMAIL PROTECTED] wrote:
Hi, all
What should I do if I want to have 2 completely seperated databases in
PostgreSQL? I want each database to have its own data, log and
everything needed to access that database. I don't want them to share
anything. Has anyone done
What would be useful for that (as of 7.5) is a dummy ALTER TABLE TYPE,
viz
ALTER TABLE tab ALTER COLUMN col TYPE same-type-it-already-has
I think we should add special syntax for this purpose, since I would like to
(or someone else later on) see all possible cases of alter column
James Robinson wrote:
Users are primarily, if not stupid, ignorant. They will read the
absolute
minimum needed to achieve a goal and little else. I say this with the
utmost respect, because I and probably everyone else on this group is
guilty of the same thing. So, the preferred installation
Yes, that is generally the case (prefer pg_xlog on separate spindle),
but no
need to *forcibly* overcomplicate things if the box has only one
spindle,
or if they have only one single RAID'd partition configured. We should
continue to err on the side of keeping the path to a functional system
James Robinson wrote:
Users are primarily, if not stupid, ignorant. They will read the
absolute
minimum needed to achieve a goal and little else. I say this with the
utmost respect, because I and probably everyone else on this group is
guilty of the same thing. So, the preferred
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Wed, 26 May 2004, Tom Lane wrote:
I'm not real sure where to document this
trick but it seems like we ought to mention it someplace.
Isn't it better to detect a UPDATE without a where and do that update in
the same way as the alter table above?
I did a CLUSTER - it took just under 12 hours. The original load of the
table (including parsing all the geometries) took about 4 hours (+4 to
build the indexes and vacuum analyse). I dont know why the cluster is
so much slower...
My SELECT * FROM table LIMIT 1; is now fast.
Thanks for the
Mohawksoft:
I forgot to specify that tablepaces should be on separate volumes. (sorry)
If all they have is one volume, no worries, but instructing the use of
alternate volumes for system and data will improve performance by
separating WAL and data operations.
... and the place for this is
[EMAIL PROTECTED] wrote:
James Robinson wrote:
Users are primarily, if not stupid, ignorant. They will read the
absolute
minimum needed to achieve a goal and little else. I say this with the
utmost respect, because I and probably everyone else on this group is
guilty of the same thing. So,
In the age of inexpensive RAID, tablespaces have more or less lost their
relevance regarding performance. pgsql's philosophy respects this by
leaving the storage work up to the OS and disk subsystem. Even having
the xlog on a different spindle won't help too much; you'll probably be
better
[EMAIL PROTECTED] wrote:
James Robinson wrote:
Users are primarily, if not stupid, ignorant. They will read the
absolute
minimum needed to achieve a goal and little else. I say this with the
utmost respect, because I and probably everyone else on this group is
guilty of the same thing. So,
Mohawksoft:
I forgot to specify that tablepaces should be on separate volumes.
(sorry)
If all they have is one volume, no worries, but instructing the use of
alternate volumes for system and data will improve performance by
separating WAL and data operations.
... and the place for this is
[EMAIL PROTECTED] wrote:
As you can see, it takes a LOT longer. That's because the disk has to do a
lot more work, the hardware data path has to carry twice as much data, and
you have to manage multiple accesses to a single object, the disk.
It doesn't take much imagination to see what this would
On Wed, 26 May 2004 18:17:55 -0400, Tom Lane [EMAIL PROTECTED] wrote:
(Some days I think we should dump
VACUUM FULL, because it's optimized for a case that's no longer very
interesting...)
So we still have to stick with VACUUM FULL for some time, right?
The next set of compatibility breakers I'm
Manfred Koizar [EMAIL PROTECTED] writes:
XX.. ..y.
and when y is updated the new version will be stored in a lower block
Oh? What makes you think that? I see no guarantee of it.
AFAICS this would make vacuum.c much simpler (no more chain moves).
How will
Jeff wrote:
Do we have any numbers as to how much this will help things?
No, I haven't done any benchmarking yet (I might do some before I
leave for the summer, but it's not a priority...)
FWIW, the performance improvement from this patch won't be as large
as it might be, since Tom already
On Thu, 27 May 2004 14:23:07 -0400, Tom Lane [EMAIL PROTECTED] wrote:
and when y is updated the new version will be stored in a lower block
Oh? What makes you think that? I see no guarantee of it.
You're right, I see only a tendency, because the majority of free space
is before the last block
Can some one help me in the question !!!
Given the Oid of a relation .. how to get the Oid of the Primary key index
on that relation ?
Thanks in adv,
-Ramu
_
Post Classifieds on MSN classifieds. http://go.msnserver.com/IN/44045.asp
[EMAIL PROTECTED] wrote:
As you can see, it takes a LOT longer. That's because the disk has to do
a
lot more work, the hardware data path has to carry twice as much data,
and
you have to manage multiple accesses to a single object, the disk.
It doesn't take much imagination to see what this
Nearing our June 1 feature freeze, we now have patches for all our major
outstanding features. Their status is:
Win32 - almost done, fsync needed, bug fixes, etc
PITR - Simon is away until Sunday and we are working on it
Nested transactions - patch needs review, trigger
On Thu, May 27, 2004 at 09:52:30PM +0200, Manfred Koizar wrote:
I have no clear explanation at the moment, just some fuzzy ideas that
are beginning to crystallise. I'm messing around with heap tuple
headers again, and the Xvac field seems to get in the way, unless I can
cut down the number
[EMAIL PROTECTED] wrote:
You are absolutely wrong on all accounts here. A RAID5 system is slower
than a single spindle as it is only as fast as the slowest disk in the
stripe and the overhead of the RAID.
Huh, what kind of controller do you use... Sounds like some value IDE
one. I'd never
On May 27, 2004 01:38 pm, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
As you can see, it takes a LOT longer. That's because the disk has to do
a
lot more work, the hardware data path has to carry twice as much data,
and
you have to manage multiple accesses to a single object, the
On Fri, 2004-05-28 at 06:07, Ramanujam H S Iyengar wrote:
Can some one help me in the question !!!
Given the Oid of a relation .. how to get the Oid of the Primary key index
on that relation ?
Attached, a couple of function I wrote that might do what you're after.
Thanks in adv,
Hackers
Are there any default query rewrite rules that kick in, in the absence
of any user-defined RULE or VIEW ?
Also, is there any place that lists any interesting query rewrite
that PG does on queries for perf. improvement ?
For instance, in the presence of a view or a subquery, does PG do
On Thu, May 27, 2004 at 05:14:48PM -0700, Sailesh Krishnamurthy wrote:
Are there any default query rewrite rules that kick in, in the absence
of any user-defined RULE or VIEW ?
Also, is there any place that lists any interesting query rewrite
that PG does on queries for perf. improvement ?
One other huge advantage that tablespaces will bring, it the ability to
place
data based on cost ie, you can put your 10 most used tables on fast disk
(or perhaps solid state devices), and move the seldom used data off onto
the
slower (lower cost) disks/storage array.
Great idea.
Hi Bruce,
Is that core's decision that:
o below all four major features will be incorporated into 7.5
o beta freeze will be June 1
In the upcoming big event Linux World (in Tokyo, from June 2 to 4) I
need to present about current status of PostgreSQL development. Even
if cores have not decided
Alvaro == Alvaro Herrera [EMAIL PROTECTED] writes:
For instance, in the presence of a view or a subquery, does PG
do a subquery to join transformation ?
Alvaro Yes, there are transformations of this sort, but they are
Alvaro not called query rewrite in the code's terminology,
Nearing our June 1 feature freeze, we now have patches for all our major
outstanding features. Their status is:
Win32 - almost done, fsync needed, bug fixes, etc
PITR - Simon is away until Sunday and we are working on it
Nested transactions - patch needs review, trigger
I've encountered a situation where I'd like to store some information
about the database when I do a pg_dump. For instance, the timestamp of
the dump. And some other information that I pull from the database.
If pg_dump had a --comment flag that allowed me to pass a string that
would be stored
Hi List!
I have discussed the following problem with pl/pgsql on irc://freenode/postgresql.
irc://freenode/postgresql
Christopher Kings-Lynne has asked me to post the problem here as a feature request, so
here goes:
I think it is best formulated in plpgsql code below.
Kris Jurka has mentioned
On Thu, May 27, 2004 at 06:27:47PM -0700, Sailesh Krishnamurthy wrote:
Alvaro == Alvaro Herrera [EMAIL PROTECTED] writes:
For instance, in the presence of a view or a subquery, does PG
do a subquery to join transformation ?
Alvaro Yes, there are transformations of this sort,
Alvaro == Alvaro Herrera [EMAIL PROTECTED] writes:
I understand that there is a cost-based optimizer anyway that
does the planning and selects the right plan .. but does this
come _after_ all these transformations ? Or does it happen
along with the transformations ?
Tatsuo Ishii wrote:
Hi Bruce,
Is that core's decision that:
o below all four major features will be incorporated into 7.5
We don't know. If they can be added to CVS without major changes, they
will be in 7.5. As far as I can tell:
Win32 has 98% of its code in CVS, so it will
I've encountered a situation where I'd like to store some information
about the database when I do a pg_dump. For instance, the timestamp of
the dump. And some other information that I pull from the database.
I think every dump should dump the timestamp regardless...
Chris
Hackers,
I am updating the ScanLists so they can be dropped at subtransaction
abort. Currently they are stored with custom next pointers; however
it would be much cleaner to deal with deleting single items if they were
Lists. Is it OK if I change them to be so?
--
Alvaro Herrera
Tatsuo Ishii wrote:
Ok, BTW have we decided that next verison is marked as 7.5 or 8.0?
No. Some argue that an 8.0 should only be done if we break backward
compatibility, while others feel major features should cause an 8.0.
--
Bruce Momjian| http://candle.pha.pa.us
I am updating the ScanLists so they can be dropped at subtransaction
abort. Currently they are stored with custom next pointers; however
it would be much cleaner to deal with deleting single items if they were
Lists. Is it OK if I change them to be so?
Alvaro,
Have I mentioned that you're a
On Thu, May 27, 2004 at 07:35:56PM -0700, Sailesh Krishnamurthy wrote:
Anyway, thanks for the tips. I think I found what I'm looking for: the
function is probably pull_up_subqueries .. and what it tries to do is
check if a subquery is simple or not .. simple means not having
Aggs or something
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
Now my next question is more subtle ..
Are these alternatives (pulling up vs not pulling up subqueries)
considered in different plans ?
That particular choice is not --- we do it if we can, else not.
Comparisons between different alternatives
Bruce Momjian [EMAIL PROTECTED] writes:
Tatsuo Ishii wrote:
Ok, BTW have we decided that next verison is marked as 7.5 or 8.0?
No. Some argue that an 8.0 should only be done if we break backward
compatibility, while others feel major features should cause an 8.0.
In any case, it's premature
44 matches
Mail list logo
