patch, which,
as I understand it, has been held up for quite a while simply because he is
concerned about this issue?
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http
Ühel kenal päeval, K, 2006-05-24 kell 09:40, kirjutas Tom Lane:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-24 at 11:17 +0300, Hannu Krosing wrote:
Why never set back again ? I'd guess that it should be set back to
true when it is not an inherited column anymore, that is when its
, yes, I think we do. I can imagine that the ability to swap a table
Agreed. Simon, were you testing how many ppl read to the end :-)
Just seeing who cared. DROP TABLE removes inheritance too, in a Keyser
Soze manner.
Just fyi - I care too .
--
Hannu Krosing
Database
(parent);
ALTER TABLE childN ALTER INHERITS ADD (parent);
With this syntax reparenting would need an explicit transaction and two
ALTER TABLE ... ALTER INHERITS ... commands, but it is (arguably)
harder to make mistakes.
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
new_parent;
For me DROP INHERITS oldtable sounds better than INHERITS DROP
oldtable , but it may be just me :)
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http
Ühel kenal päeval, R, 2006-05-19 kell 11:29, kirjutas Mark Woodward:
Andrew Dunstan [EMAIL PROTECTED] writes:
Mark Woodward wrote:
Again, there is so much code for MySQL, a MySQL emulation layer, MEL
for
short, could allow plug and play compatibility for open source, and
closed
-in
construct for referencing plpgsql variables, such as $.
Where is it exactly a problem which can't be solved simply by naming
your variables differently from fields?
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me
at least better than
4/1, maybe a lot better.
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
---(end of broadcast
Ühel kenal päeval, R, 2006-05-19 kell 14:39, kirjutas Jim C. Nasby:
On Fri, May 19, 2006 at 09:57:29PM +0300, Hannu Krosing wrote:
??hel kenal p??eval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
Something that's always bugged me is how horribly variables are handled
in plpgsql
in the field...
I guess our regex implementation already uses boyer-moore or similar.
Why not just expose the match position of substring('text' in 'regex')
using some function, called match_position(int searched_text, int
regex, int matchnum) ?
--
Hannu Krosing
Database Architect
should be good
for utf8 encoding if we care about language-specific case insensitivity.
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
Ühel kenal päeval, R, 2006-05-19 kell 16:12, kirjutas Jim C. Nasby:
On Fri, May 19, 2006 at 11:03:21PM +0300, Hannu Krosing wrote:
A less disruptive change would be to have some predefined record where
all local variables belong to, perhaps called 'local' or '_local_' :) so
one could access
Ühel kenal päeval, R, 2006-05-19 kell 14:57, kirjutas Jim C. Nasby:
On Fri, May 19, 2006 at 09:29:44PM +0200, Martijn van Oosterhout wrote:
On Fri, May 19, 2006 at 10:02:50PM +0300, Hannu Krosing wrote:
It's just SELECT count(*) FROM (SELECT * FROM accounts ORDER BY bid
Ühel kenal päeval, R, 2006-05-19 kell 18:18, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
I guess our regex implementation already uses boyer-moore or similar.
Why not just expose the match position of substring('text' in 'regex')
using some function, called match_position
optional for pure linux (kernel)
experience, but are still normally distributed.
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
NOTICE: This communication
Ühel kenal päeval, L, 2006-05-20 kell 01:34, kirjutas Hannu Krosing:
Ühel kenal päeval, R, 2006-05-19 kell 18:18, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
I guess our regex implementation already uses boyer-moore or similar.
Why not just expose the match position
Ühel kenal päeval, K, 2006-05-17 kell 20:17, kirjutas Jonah H. Harris:
On 5/17/06, Hannu Krosing [EMAIL PROTECTED] wrote:
Does ADA have both assignment and comparison as operators, or is
assignment a statement ?
Yes. Assignment is := and comparison is =
I meant to ask
as it doesn't get documented and
'good practice'.
What does PL/SQL use for assignment inside UPDATE statements ?
Is it SET A=B like in SQL or SET A:=B like in rest of PL/SQL ?
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Ühel kenal päeval, K, 2006-05-17 kell 12:20, kirjutas Zeugswetter
Andreas DCP SD:
Certainly, if you can't prototype a convincing performance win using
that algorithm, it's unlikely to be worth anyone's time to
look harder.
That should be easily possible with LZO. It would need to be the
or at least per-table basis.
also, we would get a lot of compression, if we could get rid of index
on toast table, and use the ctid directly.
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype
.
So allowing only := for assignment would make me very sad .
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
---(end of broadcast
Ühel kenal päeval, K, 2006-05-17 kell 16:31, kirjutas Andrew Dunstan:
Hannu Krosing wrote:
I don't think too many people are using that functionality intentionally;
I
probably write more PL/pgSQL than anyone and would regard any assignment
without := as a bug.
I do
, or is
assignment a statement ?
True dat. Almost all PL/SQL components come from ADA.
Maybe we need just pl/ADA ;) ?
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
, but avoid trying to hack
around this. It would make the bug even more resistent :-)
We have been trying to advocate such approach, but so far with modest results :(
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me
Ühel kenal päeval, E, 2006-05-15 kell 17:21, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Sven Suursoho wrote:
As for testing in actual pl/python build environment, we had objections
from
leading postgresql Tom Lane that even if we do test it at build time,
a determined
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
NOTICE: This communication contains privileged or other confidential
information. If you have received it in error, please
Ühel kenal päeval, R, 2006-05-05 kell 17:51, kirjutas Jim C. Nasby:
On Sat, May 06, 2006 at 12:09:45AM +0300, Hannu Krosing wrote:
??hel kenal p??eval, N, 2006-05-04 kell 17:23, kirjutas Jim Nasby:
I often find myself wanting to know how many transactions per second
a database
running time
max running time
I'd also like a possibility to gather information about usage of locks
for both function calls and simple DML statements.
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Ühel kenal päeval, R, 2006-03-03 kell 11:37, kirjutas Tom Lane:
Alvaro Herrera [EMAIL PROTECTED] writes:
So for you it would certainly help a lot to be able to vacuum the first
X pages of the big table, stop, release locks, create new transaction,
continue with the next X pages, lather,
Ühel kenal päeval, T, 2006-05-02 kell 00:27, kirjutas Brandon Black:
On 4/30/06, Heikki Linnakangas [EMAIL PROTECTED] wrote:
On Fri, 28 Apr 2006, Brandon Black wrote:
I dug around in CVS to have a look for this, and I did eventually find
it (well, I found the corresponding docs patch
Ühel kenal päeval, L, 2006-04-29 kell 19:41, kirjutas
[EMAIL PROTECTED]:
On Sat, Apr 29, 2006 at 05:54:19PM -0400, Tom Lane wrote:
In short, I think there's a reasonably good case to be made for losing the
hidden dependency and re-adopting the viewpoint that saying SERIAL is
*exactly* the
Ühel kenal päeval, T, 2006-04-25 kell 13:58, kirjutas Tom Lane:
Martijn van Oosterhout kleptog@svana.org writes:
I think the basic problem is that DDL can't really work within a
transaction. If I do an ALTER TABLE, some of these changes need to show
up to concurrent transactions (maybe
Ühel kenal päeval, E, 2006-04-17 kell 17:14, kirjutas Bruce Momjian:
Jim C. Nasby wrote:
Are you going to back-patch this? If I understand correctly current
behavior could mean people using PITR may have invalid backups. In the
meantime, perhaps we should send an email to -annouce
Hi
Anyone interested in plpython, please check out/review
http://archives.postgresql.org/pgsql-patches/2006-04/msg00087.php
It fixes the most obvious shortcomings of plpython by making it possible
to return both sets and records (and setof records) and to use named
input parameters in addition
Ühel kenal päeval, P, 2006-04-16 kell 11:31, kirjutas Tom Lane:
Marko Kreen [EMAIL PROTECTED] writes:
So we should probably document that rsync is only working solution.
No, we're just turning off the variable. One experiment on one version
of rsync doesn't prove it's safe, even if there
Ühel kenal päeval, R, 2006-04-14 kell 17:31, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Ühel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
If the backup-taker reads, say, 4K at a time then it's
certainly possible that it gets a later version of the second half
Ühel kenal päeval, L, 2006-04-15 kell 11:49, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
If I'm desperate enough to get the 2x reduction of WAL writes, I may
even write my own backup solution.
Given Florian's concern, sounds like you might have to write your own
kernel too
Ühel kenal päeval, R, 2006-04-14 kell 16:40, kirjutas Tom Lane:
I think we had originally argued that there was no problem anyway
because the kernel should cause the page write to appear atomic to other
processes (since we issue it in a single write() command). But that's
only true if the
Ühel kenal päeval, K, 2006-04-12 kell 10:29, kirjutas Jim C. Nasby:
On Wed, Apr 12, 2006 at 04:53:20PM +0200, Thomas Hallgren wrote:
NestedLoop cost=1.06..40.43 rows=5 width=244
JoinFilter publicTenk1Unique2=int4_tbl.f1
HashAggregate cost=1.06..1.11 rows=5 width=4/
/JoinFilter
Ühel kenal päeval, K, 2006-04-12 kell 14:38, kirjutas Jim C. Nasby:
Well, really just about anything you'd want to do with it in an XML
format. The advantage of SQL is that you can do it within the database,
and you don't have to worry about having something around that can
process XML.
Ühel kenal päeval, K, 2006-04-12 kell 17:42, kirjutas Alvaro Herrera:
It would be nice to see the visual explain tool that Denis wrote --
did he finish it? Is it available somewhere? Are there any screenshots?
IIRC there is a visual explain tool pin pgAdmin III
---
Hannu
Ühel kenal päeval, P, 2006-04-09 kell 18:26, kirjutas Martijn van
Oosterhout:
The cost of fetching a page from the OS is not really much of an
overhead,
Have you tested this ?
I remember having a case, where data load usin COPY into a table with
several indexes ran an order of magnitude
Ühel kenal päeval, L, 2006-04-08 kell 18:47, kirjutas Luke Lonergan:
I agree - there is a real continuing need for overlapped scan and execution,
though I'm not sure quite how to get it efficiently using inter-process
communication. The AIO interface is nicely proven at this point, but to
Ühel kenal päeval, E, 2006-04-03 kell 01:48, kirjutas Tom Lane:
Martin Scholes [EMAIL PROTECTED] writes:
Ok Tom, I stand corrected.
I downloaded the latest snapshot and both scenarios (normal and WAL bypass =
for indexes) produced between 185 and 230 tps on my machine.
The lesson here
Ühel kenal päeval, E, 2006-04-03 kell 09:55, kirjutas Tom Lane:
(2) Some of the index code is itself deliberately nondeterministic.
I'm thinking in particular of the move-right-or-not choice in
_bt_insertonpg() when there are many equal keys, but randomization is
in general a useful
Ühel kenal päeval, K, 2006-03-22 kell 21:50, kirjutas Andrew Dunstan:
Tom Lane said:
Darcy Buskermolen [EMAIL PROTECTED] writes:
On Wednesday 22 March 2006 13:11, Tom Lane wrote:
(Thinks a bit...) Maybe it would work for pg_sequence to be a real
catalog with a row per sequence, and we
Ühel kenal päeval, K, 2006-03-22 kell 16:11, kirjutas Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
How does one get at the missing fields. The only way I know is
selecting from the sequence, but how does one work this into this
query? Somehow it seems that these things should be
Ühel kenal päeval, K, 2006-03-22 kell 17:29, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Ühel kenal päeval, K, 2006-03-22 kell 16:11, kirjutas Tom Lane:
Yeah. I've occasionally toyed with the idea that sequences should be
rows in a single catalog instead of independent
Ühel kenal päeval, L, 2006-03-18 kell 12:38, kirjutas Rod Taylor:
This will, presumably, be a very PostgreSQL friendly group so a sales
pitch isn't really required.
How about the opposite? Tom Lanes list of areas that PostgreSQL does a
poor job and a detailed explanation as to how that
Ühel kenal päeval, R, 2006-03-17 kell 10:12, kirjutas Peter Eisentraut:
What sense is this supposed to make?
= begin;
BEGIN
= blah;
ERROR: ...
= commit;
ROLLBACK
Return status tells you what actually happened.
Even if this is justifiable, this behavior is not documented (in
Ühel kenal päeval, R, 2006-03-17 kell 11:27, kirjutas Peter Eisentraut:
Am Freitag, 17. März 2006 11:25 schrieb Hannu Krosing:
= commit;
ROLLBACK
Return status tells you what actually happened.
If I send a COMMIT, I want a commit to happen or an error.
You already got
Ühel kenal päeval, R, 2006-03-17 kell 14:10, kirjutas Peter Eisentraut:
Am Freitag, 17. März 2006 13:03 schrieb Hannu Krosing:
If I send a COMMIT, I want a commit to happen or an error.
You already got several errors.
Right, but a defensively programmed application, I want to get all
Ühel kenal päeval, R, 2006-03-17 kell 09:46, kirjutas Tom Lane:
Qingqing Zhou [EMAIL PROTECTED] writes:
So what's the difference between these two strategy?
(1) Running time: do they use the same amount of memory? Why option 2 is
better than 1?
(2) Idle time: after sort done, option 1
Ühel kenal päeval, R, 2006-03-10 kell 12:23, kirjutas Steve Atkins:
I get bitten by this quite often (customer machines, one giant table,
purge out a lot of old data).
CLUSTER is great for that, given the headroom, though I've often
resorted to a dump and restore because I've not had the
Ühel kenal päeval, K, 2006-03-08 kell 20:08, kirjutas Jim C. Nasby:
But it will take a whole lot of those rewinds to equal the amount of
time required by an additional pass through the data.
I guess that missing a sector read also implies a rewind, i.e. if you
don't process the data read from
Ühel kenal päeval, N, 2006-03-09 kell 11:35, kirjutas Jonah H. Harris:
This email is a preliminary design for the implementation of synonyms
in PostgreSQL. Comments and suggestions are welcomed.
BACKGROUND
Synonyms are database objects which can be used in place of their
referenced
Ühel kenal päeval, E, 2006-03-06 kell 17:25, kirjutas Bruce Momjian:
Hannu Krosing wrote:
?hel kenal p?eval, E, 2006-03-06 kell 12:12, kirjutas Bruce Momjian:
Added to TODO:
o Prevent parent tables from altering or dropping constraints
like CHECK that are inherited
Ühel kenal päeval, E, 2006-03-06 kell 12:12, kirjutas Bruce Momjian:
Added to TODO:
o Prevent parent tables from altering or dropping constraints
like CHECK that are inherited by child tables
Dropping constraints should only be possible with CASCADE.
and we already
Ühel kenal päeval, N, 2006-03-02 kell 22:15, kirjutas Bruce Momjian:
Is there still interst in this idea for TODO?
Just to voice my support - Yes, I think that being able to set lower
thresolds for TOAST is very useful in several cases.
Also getting rid of toast index and start using ctids
Ühel kenal päeval, L, 2006-03-04 kell 10:31, kirjutas Tom Lane:
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
Also getting rid of toast index and start using ctids directly would be
a big bonus.
When using direct ctids we
Ühel kenal päeval, L, 2006-03-04 kell 13:16, kirjutas Rod Taylor:
Adding a new partition is fairly simple, particularly if you don't care
about writing RULEs to direct data into it and can rely on a bulk loader
to figure that part out.
Removing a partition, on the other hand, is currently
Ühel kenal päeval, N, 2006-03-02 kell 09:53, kirjutas Zeugswetter
Andreas DCP SD:
I thought we had sufficiently destroyed that reuse a tuple
meme yesterday. You can't do that: there are too many
aspects of the system design that are predicated on the
assumption that dead tuples do not
Ühel kenal päeval, N, 2006-03-02 kell 10:13, kirjutas Scott Marlowe:
On Thu, 2006-03-02 at 00:45, Hannu Krosing wrote:
Ühel kenal päeval, K, 2006-03-01 kell 14:36, kirjutas Scott Marlowe:
..
We don't say 42 degrees, -12 minutes when measuring arc, do we? Then
again, maybe some folks do
Ühel kenal päeval, N, 2006-03-02 kell 15:35, kirjutas Marc G. Fournier:
Just curious, but what is involved in these invitations? For instance,
is there a limit on # of invitations any one person(?) or company can
issue? Are there any legal implications of issuing such an invitation?
Sure.
Ühel kenal päeval, K, 2006-03-01 kell 15:18, kirjutas Bruce Momjian:
Stephan Szabo wrote:
justify_days doesn't currently do anything with this result --- it
thinks its charter is only to reduce day components that are = 30 days.
However, I think a good case could be made that it should
Ühel kenal päeval, K, 2006-03-01 kell 14:36, kirjutas Scott Marlowe:
But it isn't '-2 months, -1 day'. I think what you are saying is what I
am saying, that we should make the signs consistent.
Pretty much. It just seems wrong to have different signs in what is
essentially a single
Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
on correct functioning of user-written code --- consider a functional
Ühel kenal päeval, T, 2006-02-28 kell 01:04, kirjutas Tom Lane:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Feb 27, 2006 at 03:05:41PM -0500, Tom Lane wrote:
Moreover, you haven't pointed to any strong reason to adopt this
methodology. It'd only be a win when vacuuming pretty small
Ühel kenal päeval, T, 2006-02-28 kell 10:04, kirjutas Hannu Krosing:
Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
Ühel kenal päeval, T, 2006-02-28 kell 10:26, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
There is no fundamental reason, why vacuum needs to run in a transaction
itselt.
I'll just take one point: you cannot hold locks unless you have a
transaction, therefore you cannot even
Ühel kenal päeval, T, 2006-02-28 kell 10:16, kirjutas Alvaro Herrera:
Hannu Krosing wrote:
In the big table with hotspots case, I doubt that the win from
btbulkdelete will outweight having to scan 10 index pages to get to
the 30 or 50 that can be bulkdeleted.
Remember that WAL
Ühel kenal päeval, E, 2006-02-27 kell 19:20, kirjutas Peter Eisentraut:
Something came to my mind today, I'm not sure if it's feasible but I
would like to know opinions on it.
We've seen database applications that PostgreSQL simply could not manage
because one would have to vacuum
Ühel kenal päeval, E, 2006-02-27 kell 13:17, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Vacuum will need to be modified to use index lookups to find index tuples
corresponding the dead heap tuples. Otherwise you have to scan through
all the indexes anyway.
This
Ühel kenal päeval, P, 2006-02-26 kell 09:31, kirjutas Luke Lonergan:
Jim,
On 2/26/06 8:00 AM, Jim C. Nasby [EMAIL PROTECTED] wrote:
Any idea on how decompression time compares to IO bandwidth? In other
words, how long does it take to decompress 1MB vs read that 1MB vs read
whatever the
Ühel kenal päeval, L, 2006-02-25 kell 10:09, kirjutas Tino Wildenhain:
James Robinson schrieb:
I see neilc has hacked on it very recently to reduce memory leaks. I
take that as both good and bad signs.
We're a [ small ] python shop, and would be most interested in being
able to
Ühel kenal päeval, R, 2006-02-24 kell 19:20, kirjutas Csaba Nagy:
On Fri, 2006-02-24 at 19:12, Rod Taylor wrote:
On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I watch for table bloat but I haven't figured out a nice way of tracking
down the
Ühel kenal päeval, K, 2006-02-22 kell 16:02, kirjutas Shaun Thomas:
I'm in charge of a very large database, and we're using a highly decrepit
version of Postgresql currently.
After searching through the archives, Google, and trying out several
replication engines, I have a question.
I
Ühel kenal päeval, K, 2006-02-08 kell 12:26, kirjutas Fredrik Olsson:
I have private tables such as this (Very simplified):
CREATE TABLE private.t_foo (
...
);
REVOKE ALL ON private.t_foo FROM public;
Different users have access to different data in the table, so I do
this view:
Ühel kenal päeval, K, 2006-02-08 kell 15:51, kirjutas Tom Lane:
Josh Berkus josh@agliodbs.com writes:
This would be a very fine project for someone to pick up (maybe one of
the corporate supporters could sponsor someone to work on it?)
We looked at it for Greenplum but just couldn't
Ühel kenal päeval, K, 2006-02-01 kell 18:08, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Does ALTER TABLE SET TABLESPACE lock the table
It had better ... see nearby discussion about relaxing locking for
TRUNCATE.
Is it some recent disussion ?
Exactly the same problem
Does ALTER TABLE SET TABLESPACE lock the table while copying data to new
location ?
If so, then does it lock the whole table, or just the tuples belonging
to currently copied 1G file ?
Hannu
---(end of broadcast)---
TIP 9: In
Ühel kenal päeval, N, 2006-01-19 kell 14:25, kirjutas uwcssa:
I have a simple question here, not sure if i should posted here but
if you have the quick answer, it helps a lot
i have a table that is already vacuumed. for some reason i want
to un-vacuum it instead of dropping the table and
Ühel kenal päeval, K, 2006-01-18 kell 22:35, kirjutas uwcssa:
I am testing the performance of postgresql on a set of workloads.
However,
the output significantly affects the performance evaluation. Is there
a way
to by-pass all output of select statements so the timing reflects only
the
Ühel kenal päeval, P, 2006-01-08 kell 11:49, kirjutas Greg Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
Interestingly I use pg_stat_activity view to watch for stuck backends,
stuck in the sense that they have not noticed when client want away
and are now waitin the TCP timeout to happen
Ühel kenal päeval, T, 2006-01-03 kell 09:40, kirjutas Simon Riggs:
We can also save lots of cycles on the current statement overhead, which
is currently the worst part of the stats, performance-wise. That
definitely needs redesign. AFAICS we only ever need to know the SQL
statement via the
Ühel kenal päeval, E, 2006-01-02 kell 15:20, kirjutas Tom Lane:
[ moving to -hackers ]
Bruce Momjian pgman@candle.pha.pa.us writes:
I did some research on this because the numbers Tom quotes indicate there
is something wrong in the way we process stats_command_string
statistics.
[ ...
Ühel kenal päeval, T, 2005-12-27 kell 19:20, kirjutas Martijn van
Oosterhout:
On Mon, Dec 26, 2005 at 11:00:51AM -0500, Bruce Momjian wrote:
I think this brings up an interesting distinction, that having the NO
LOGGING switch per command doesn't make sense because it modifying the
table.
Ühel kenal päeval, R, 2005-12-23 kell 23:06, kirjutas Tom Lane:
Greg Stark [EMAIL PROTECTED] writes:
It seems to me the only rational way to approach this is to have a per-table
flag that sets that table to be non-logged. Essentially changing a table's
behaviour to that of a temporary table
Ü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
Ühel kenal päeval, K, 2005-12-21 kell 09:50, kirjutas Hannu Krosing:
Ühel kenal päeval, T, 2005-12-20 kell 17:18, kirjutas Tom Lane:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
i was just wondering about the status of hannu's concurrent vacuum patch.
are there any
Ühel kenal päeval, T, 2005-12-20 kell 17:18, kirjutas Tom Lane:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
i was just wondering about the status of hannu's concurrent vacuum patch.
are there any plans to integrate this
I still don't trust it (assuming that you're
Ühel kenal päeval, K, 2005-12-14 kell 01:52, kirjutas David Fetter:
Folks,
I'm trying to come up with a design for \ commands in psql in 8.2.
8.1 broke just about every \ command because they now depend on roles,
which is great for 8.1 or better, but not so good if you're connecting
to DBs
Ühel kenal päeval, L, 2005-12-10 kell 21:07, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
How do you plan to determine any rows not already present in the index
without explicitly remembering the start and end snapshots of existing
CREATE INDEX (SNAP1 and SNAP2 in my proposal
Ühel kenal päeval, P, 2005-12-11 kell 17:55, kirjutas Carlos Moreno:
Hi,
I'm very new to this list -- I've been using and advocating PostgreSQL for
no less than 4 or 5 years now, and have participated in some of the other
mailing lists, but never on this one.
My question is (short
Ühel kenal päeval, N, 2005-12-08 kell 14:53, kirjutas Tom Lane:
Given the discussion so far, it seems likely to me that completely
concurrent REINDEX is indeed out of reach, and that what we ought to
be thinking about is what sort of compromise design (ie, partially
concurrent REINDEX) is
Ühel kenal päeval, N, 2005-12-08 kell 01:08, kirjutas Jim C. Nasby:
On Thu, Dec 08, 2005 at 08:57:42AM +0200, Hannu Krosing wrote:
??hel kenal p??eval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED
Ühel kenal päeval, N, 2005-12-08 kell 11:10, kirjutas Simon Riggs:
On Wed, 2005-12-07 at 21:24 +, Simon Riggs wrote:
Following patch implements record of whether a constraint is inherited
or not, and prevents dropping of inherited constraints.
Patch posted to -patches list.
What it
Ühel kenal päeval, K, 2005-12-07 kell 13:36, kirjutas Greg Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
But that said, realistically *any* solution has to obtain a lock at some
time
to make the schema change. I would say pretty much any O(1) (constant
time)
outage is at least
Ühel kenal päeval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to rescan the entire
table to be sure you haven't missed anything. So in
901 - 1000 of 1744 matches
Mail list logo
