On Wed, 2005-12-21 at 23:50 -0500, Tom Lane wrote:
Manuel Sugawara masm@fciencias.unam.mx writes:
Tom Lane [EMAIL PROTECTED] writes:
I thought to_char already had i18n behavior. What exactly are you
thinking of changing?
The modifiers that are suitable to localize. Month and day names
Jim C. Nasby wrote:
On Wed, Dec 21, 2005 at 05:43:38PM -0500, Bruce Momjian wrote:
Rick Gigger wrote:
It seems to me like there are two classes of problems here:
1) Simply invalidating plans made with out of date statistics.
2) Using run-time collected data to update the plan to something
Hello
Now, statements EXECUTE INTO and SELECT INTO allow using list of scalars.
FORe and FORs allow only ROW o RECORD VARIABLE. I'll plan and I did it
enhance this stmts:
for := FOR target IN {SELECT | EXECUTE} ... LOOP
target := {row|record|comma separated list of scalar vars}
assign :=
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row before the offset ?
Le mercredi 21 décembre 2005 à 13:41 -0600, Jim C. Nasby a écrit :
Have you tried
SELECT *, test_func(idkeyword)
FROM
On Thu, Dec 22, 2005 at 10:52:58AM +0100, REYNAUD Jean-Samuel wrote:
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row before the offset ?
Well, saying offset 5000 pretty much means to calculate
On Wed, 2005-12-21 at 19:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
While we scan, if we found two adjacent pages, both of which have less
than (say) 40% rows, we could re-join or unsplit those pages together.
Curiously enough, this has been thought of before. It is
On Mon, 2005-12-19 at 17:17 +0900, OKADA Satoshi wrote:
Tom Lane wrote:
OKADA Satoshi [EMAIL PROTECTED] writes:
The loss of log was simulated by deleting the latest xlog file.
What does that have to do with reality? Postgres is very careful not to
use an xlog file until
On Thu, Dec 22, 2005 at 10:53:39AM +, Simon Riggs wrote:
IMHO the problem is the deletion of the xlog file, not the error
message.
If you *did* lose an xlog file, would you not expect the system to come
up anyway? You're saying that you'd want the system to stay down because
of this?
Is it possible to just not replicate the internal tsearch tables ?
Dave
On 21-Dec-05, at 4:37 PM, Dave Cramer wrote:
Thanks, that might be easier than first thought.
Dave
On 21-Dec-05, at 2:04 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
Is it possible to add the old
--- Karel Zak [EMAIL PROTECTED] escreveu:
I have a patch like this. But this was for 7.4.x. I have to take a look
at it.
That's important point. How resolve this problem Oracle? Maybe we can
say (in docs) that with non-English locales it works with days/months
names as in FM (fill) mode.
Having just optimized COPY to avoid writing WAL during the transaction
in which a table was first created, it seems worth considering whether
this should occur for INSERT, UPDATE and DELETE also.
It is fairly common to do data transformation using INSERT SELECTs and
UPDATEs. This is usually done
Simon Riggs [EMAIL PROTECTED] writes:
Sorry, I missed that.
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from one to the other. If you move items
from one page to the
On Thu, Dec 22, 2005 at 10:40:24AM -0500, Tom Lane wrote:
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from one to the other. If you move items
from one page to the
Pavel Stehule [EMAIL PROTECTED] writes:
for := FOR target IN {SELECT | EXECUTE} ... LOOP
target := {row|record|comma separated list of scalar vars}
This part seems all right to me.
assign := target2 ':=' expression
target2 := {row|record|variable|'ROW(' comma separated list of scalar vars
Simon Riggs [EMAIL PROTECTED] writes:
Currently, CTAS optimization requires a heap_sync during ExecEndPlan. It
would be easy enough to extend this so that it also works for INSERT,
UPDATE and DELETE.
If you tried to do it that way you'd break the system completely. Not
all updates go through
On Thu, Dec 22, 2005 at 02:31:33PM +, Simon Riggs wrote:
Having just optimized COPY to avoid writing WAL during the transaction
in which a table was first created, it seems worth considering whether
this should occur for INSERT, UPDATE and DELETE also.
It is fairly common to do data
BTW, this should also probably be moved over to -hackers...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of
Martijn van Oosterhout wrote:
The downsides are probably that it's a pain to make it work
concurrently and requires writing each index page at least twice. But
it's a thought...
We already do something similar for page deletions. Empty pages are not
deleted right away, but they are marked
On Wed, Dec 21, 2005 at 11:00:31PM -0500, Bruce Momjian wrote:
Track normal resource consumption (ie: tuples read) for planned queries
and record parameter values that result in drastically different
resource consumption.
This would at least make it easy for admins to identify prepared
On Thu, 2005-12-22 at 12:12 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Currently, CTAS optimization requires a heap_sync during ExecEndPlan. It
would be easy enough to extend this so that it also works for INSERT,
UPDATE and DELETE.
If you tried to do it that way you'd
Alvaro Herrera [EMAIL PROTECTED] writes:
We already do something similar for page deletions. Empty pages are not
deleted right away, but they are marked with BTP_DEAD, and then deleted
on a subsequent vacuum. Or something like that, I don't remember the
exact details.
Right, and the reason
Oh, OK, so you are logging prepared queries where the plan generates a
significantly different number of rows from previous runs. I am not
sure why that is better, or easier, than just invalidating the cached
plan if the cardinality changes.
On Thu, Dec 22, 2005 at 12:37:51PM -0600, Jim C. Nasby wrote:
I do think this needs to be something that is made either completely
transparent or must be specifically enabled. As described, I believe
this would break PITR, so users should have to specifically request that
behavior (and they
Jim C. Nasby wrote:
Now, if both of these are done using a prepared statement, it's going to
look like:
SELECT * FROM queue WHERE status='?';
If the first one to run is the queue processing one, the planner will
probably choose the index. This means that when we're searching on 'N',
there
Lukas Smith wrote:
Jim C. Nasby wrote:
Now, if both of these are done using a prepared statement, it's going to
look like:
SELECT * FROM queue WHERE status='?';
If the first one to run is the queue processing one, the planner will
probably choose the index. This means that when
Bruce Momjian wrote:
Maybe I am mixing up separate concepts (are bound variables and prepared
statements different concepts?) here. I also do not really understand if
that means that oracle does not store a query plan for a prepared query
or if it just does some special handling in case it
On Thu, Dec 22, 2005 at 10:18:16AM +0100, Pavel Stehule wrote:
Hello
Now, statements EXECUTE INTO and SELECT INTO allow using list of scalars.
FORe and FORs allow only ROW o RECORD VARIABLE. I'll plan and I did it
enhance this stmts:
for := FOR target IN {SELECT | EXECUTE} ... LOOP
On Thu, Dec 22, 2005 at 09:55:14PM +0100, Lukas Smith wrote:
Bruce Momjian wrote:
Maybe I am mixing up separate concepts (are bound variables and prepared
statements different concepts?) here. I also do not really understand if
that means that oracle does not store a query plan for a
Lukas Smith wrote:
Bruce Momjian wrote:
Maybe I am mixing up separate concepts (are bound variables and prepared
statements different concepts?) here. I also do not really understand if
that means that oracle does not store a query plan for a prepared query
or if it just does some
Bruce Momjian wrote:
It is an issue for all databases. We gave a TODO about it:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Ok, just so I
Well, not just rows; total tuples, both base heap and index. ISTM that
would be a better metric than just plain rows read out of base or rows
returned.
Depending on how far down this road we want to go, this would allow for
detecting what parameter values require different query plans, and then
On Thu, Dec 22, 2005 at 10:14:15PM +0100, Lukas Smith wrote:
Ok, just so I understand this correctly. In the mentioned case the
cardinality does not really change in regards to the table stats, its
just thatI happen to use a value that has a different selectivity and
therefore I may need a
We need invalidation anyway, so I don't see why an intermediate step
makes sense.
---
Jim C. Nasby wrote:
Well, not just rows; total tuples, both base heap and index. ISTM that
would be a better metric than just plain
Bruce Momjian wrote:
Right, if the cardinality changes, you realize this before execution and
optimize/save the plan again. A further optimization would be to save
_multiple_ plans for a single prepared plan based on constants and
choose one of the other, but that is beyond where we are
On Thu, Dec 22, 2005 at 11:18:22AM +0100, Martijn van Oosterhout wrote:
On Thu, Dec 22, 2005 at 10:52:58AM +0100, REYNAUD Jean-Samuel wrote:
Hi
I've just tried it, and it works. So it's a good work-around.
Though, is it a wanted feature to have a function being performed on
each row
On Thu, 22 Dec 2005 08:01:00 +0100, Martijn van Oosterhout
kleptog@svana.org wrote:
But where are you including the cost to check how many cells are
already sorted? That would be O(H), right?
Yes. I didn't mention it, because H N.
This is where we come back
to the issue that comparisons in
On Thu, 2005-12-22 at 10:40 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Sorry, I missed that.
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from
On Thu, 2005-12-22 at 21:18 +0100, Martijn van Oosterhout wrote:
Considering WAL bypass is code for breaks PITR
No it isn't. All of the WAL bypass logic does *not* operate when PITR is
active. The WAL bypass logic is aimed at Data Warehouses, which
typically never operate in PITR mode for
An interesting article on sorting and comparison count:
http://www.acm.org/jea/ARTICLES/Vol7Nbr5.pdf
Here is the article, the code, and an implementation that I have been
toying with:
http://cap.connx.com/chess-engines/new-approach/algos.zip
Algorithm quickheap is especially interesting because
* Simon Riggs ([EMAIL PROTECTED]) wrote:
On Thu, 2005-12-22 at 21:18 +0100, Martijn van Oosterhout wrote:
Considering WAL bypass is code for breaks PITR
No it isn't. All of the WAL bypass logic does *not* operate when PITR is
active. The WAL bypass logic is aimed at Data Warehouses, which
On Thursday 2005-12-22 14:28, Lukas Kahwe Smith wrote:
Bruce Momjian wrote:
Right, if the cardinality changes, you realize this before execution and
optimize/save the plan again. A further optimization would be to save
_multiple_ plans for a single prepared plan based on constants and
Trent Shipley wrote:
On Thursday 2005-12-22 14:28, Lukas Kahwe Smith wrote:
Bruce Momjian wrote:
Right, if the cardinality changes, you realize this before execution and
optimize/save the plan again. A further optimization would be to save
_multiple_ plans for a single prepared plan
Jim C. Nasby wrote:
On Sat, Dec 17, 2005 at 04:59:45PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Looking before that, the 64-bit registers are now prefixed with 'r'
instead of 'e', so what I did was to convert all the long/l assembler
Hi ,
Here is the requirements :
1. Development Support team can ONLY have READ Only ACCESS
to PRODUCTION Database. They will NOT have access to create
stored procedure functions in the PRODUCTION on the fly.
2. During application support, need to write script which
uses procedural
Ashok Agrawal wrote:
Hi ,
Here is the requirements :
1. Development Support team can ONLY have READ Only ACCESS
to PRODUCTION Database. They will NOT have access to create
stored procedure functions in the PRODUCTION on the fly.
2. During application support, need to write
David Fetter [EMAIL PROTECTED] writes:
How about:
target2 := {row|record|variable|'[ROW](' comma separated list of scalar
vars ')'}
instead, where the ROW is optional?
If we're going to do this at all (which I'm still agin), I think the ROW
keyword is important to minimize ambiguity. If you
Ühel kenal päeval, N, 2005-12-22 kell 18:19, kirjutas Bruce Momjian:
Ashok Agrawal wrote:
Hi ,
Here is the requirements :
1. Development Support team can ONLY have READ Only ACCESS
to PRODUCTION Database. They will NOT have access to create
stored procedure functions in
Hi
Could anybody tell me what is the smallest working page size for
postgresql ?
I have a table where access is highly random over huge table getting
usually only one small tuple from each page. One way to get more
performance could be using smaller page size, so the per-tuple read
overhead
Hannu Krosing wrote:
?hel kenal p?eval, N, 2005-12-22 kell 18:19, kirjutas Bruce Momjian:
Ashok Agrawal wrote:
Hi ,
Here is the requirements :
1. Development Support team can ONLY have READ Only ACCESS
to PRODUCTION Database. They will NOT have access to create
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
So it appears that pg_md5_encrypt is not officially exported from libpq.
Does anyone see a problem with adding it to the export list and the
header file?
Is it different to normal md5? How is this helpful to
Simon Riggs [EMAIL PROTECTED] wrote
No it isn't. All of the WAL bypass logic does *not* operate when PITR is
active. The WAL bypass logic is aimed at Data Warehouses, which
typically never operate in PITR mode for performance reasons, however
the choice is yours.
To make things, is it
Andrew Dunstan [EMAIL PROTECTED] writes:
Where are we on this? In general I agree with Tom, but I have no time to
do the work. Unless someone has an immediate implementation, I suggest
that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
which is the minimum needed to
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
How about:
target2 := {row|record|variable|'[ROW](' comma separated list of scalar vars
')'}
instead, where the ROW is optional?
If we're going to do this at all (which I'm still agin), I think the ROW
keyword is important to
Qingqing Zhou [EMAIL PROTECTED] wrote
To make things, is it possible to add a GUC to let user disable *all* the
xlogs?
It may work like this:
BEGIN TRANSACTION WITHOUT XLOG;/* forbidden vacuum, PITR etc */
BEGIN
.../* no xlog during this peroid */
END; /* don't mark this
I don't need ability to sit at a prompt and type stuff.
To be more clear, I am attaching one sample code. I would like to
migrate this code using postgres without converting into procedure
or function.
Thanks
Ashok
Bruce Momjian wrote On 12/22/05 15:35,:
Hannu Krosing wrote:
?hel kenal
Qingqing Zhou [EMAIL PROTECTED] writes:
BEGIN TRANSACTION WITHOUT XLOG;/* forbidden vacuum, PITR etc */
So during this peroid, if any transaction failed, the only consequence is
add invisible garbage data.
No, the likely consequence is irretrievable corruption of any table or
index page
Wow, that is large. I think PL/pgSQL is your best approach. I
recommend you create a schema that users can write into.
---
Ashok Agrawal wrote:
I don't need ability to sit at a prompt and type stuff.
To be more clear,
Tom Lane [EMAIL PROTECTED] wrote
Qingqing Zhou [EMAIL PROTECTED] writes:
BEGIN TRANSACTION WITHOUT XLOG;/* forbidden vacuum, PITR etc */
So during this peroid, if any transaction failed, the only consequence is
add invisible garbage data.
No, the likely consequence is irretrievable
I wrote:
I had forgotten that the Windows build is broken. I'll see what I can
do with throwing together the cleaner-API function.
Done, but I noticed that the change to createuser has arguably broken
it; at least we need to change the docs. To wit, the docs say
-E
--encrypted
Encrypts
Hannu Krosing [EMAIL PROTECTED] wrote
Could anybody tell me what is the smallest working page size for
postgresql ?
I have a table where access is highly random over huge table getting
usually only one small tuple from each page. One way to get more
performance could be using smaller page
Where are we on this? In general I agree with Tom, but I have no time to
do the work. Unless someone has an immediate implementation, I suggest
that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
which is the minimum needed to unbreak Windows builds, while this gets
sorted
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
So, can I specify the password to pg_connect() as
'md5127349123742342344234'?
Certainly not. We'd hardly be worrying about obscuring the original
password if the encrypted version were enough to get in with.
regards,
Qingqing Zhou [EMAIL PROTECTED] writes:
I guess I know (at least part) of what you mean. This is because we rely on
replay all the xlog no matter it belongs to a committed transaction or not.
Why? Because a failed transaction is not totally useless since later
transaction may reply on some
So, can I specify the password to pg_connect() as
'md5127349123742342344234'?
Certainly not. We'd hardly be worrying about obscuring the original
password if the encrypted version were enough to get in with.
AndrewSN can't post at the moment, but asked me to post this for him:
Knowing the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
AndrewSN can't post at the moment, but asked me to post this for him:
Knowing the md5 hash is enough to authenticate via the 'md5' method in
pg_hba.conf, even if you don't know the original password.
If you know the md5 hash, you know
65 matches
Mail list logo
