> > > 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
Neil Conway <[EMAIL PROTECTED]> writes:
>> If not, would something like a pg_bench exercise the new code enough to
>> see the results?
> Something like TPC-H would be better, I'd think.
You'd only be likely to notice a difference in queries with hundreds of
selected columns, CASE expressions wit
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 prem
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 alternati
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 so
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 tot
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
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 ()
"Uno comb
Ok, BTW have we decided that next verison is marked as 7.5 or 8.0?
--
Tatsuo Ishii
> 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 change
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
---
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
> "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 transformat
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 transforma
Hi List!
I have discussed the following problem with pl/pgsql on 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 that something like this mig
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
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 iss
> "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
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
> 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.
-
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. improvem
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 d
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,
>
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 singl
> [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.
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 numbe
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 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
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
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
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 repla
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
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
[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 m
> "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 pl
> [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
> 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
> bette
[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, 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
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 LIMIT 1;" is now fast.
Thanks for the help!
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
> 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, t
> 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 s
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 pr
> 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"
44 matches
Mail list logo
