>
> + if (strcmp(te->desc,"CONSTRAINT") == 0
> ||
> + strcmp(te->desc,"FK
> CONSTRAINT") == 0 ||
> + strcmp(te->desc,"CHECK
> CONSTRAINT") == 0 ||
> +
Andrew Dunstan wrote:
> Unfortunately, it quite possibly would. You would not be able to build
> two indexes on the same table in parallel, even though they wouldn't
> have conflicting locks.
I suppose so, but:
1. By the same logic it might speed things up; it might build two
completely separate i
Another 0.02c, bringing the grand total to 0.04c.
Andrew Dunstan wrote:
> First, we need a way to decide the boundary between the serially run
> "pre-data" section and the remainder of the items in the TOC.
> Currently the code uses the first TABLEDATA item as the boundary.
> That's not terribly
Tom Lane wrote:
>> How about printing that notice at the top of the dump file as well?
>>
>
> Hmm ... that might be feasible in plain text output, but I don't see
> any easy way to get a similar effect in archive modes.
>
Just saw this, obviously very late, but from memory there is a TOC e
duce such contention.
--
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 03 5330 3171 | __
Sorry, should RTFM more closely:
"If a transaction is waiting for a row-level lock, it will usually
appear in the view as waiting for the transaction ID
of the current holder of that row lock."
so I need to look at the row locks on the blocker.
Philip Warner wrote:
>
Tom Lane wrote:
> Neither are we, because you left out all the columns that might tell
> that ...
>
The columns are actually blankit's the other rows I left out with
the row-level locks:
925282231 | 925280527 | | 62814 | RowExclusiveLock| t
925282208 | 925280527 |
looking at offloading are large summary-type
sequential scans of big tables.
--
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498
Alex Hunsaker wrote
>
> Uhh sounds like you are describing hot standby (currently in the works
> for 8.4) see:
>
Yep. That's exactly what I'm talking about. Thanks for the links!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
-disk
formats. Question is:
Is there a simple way to determine compatibility? (eg. a small
well-defined list of requirements)
In the specific instance I am working with, I'd like to copy from 64 bit
AMD BSD system to a 64 bit Linux system.
Philip Warner
--
Sent via pgsql-hackers mailing
Jeff Davis wrote:
> On Tue, 2008-12-02 at 16:21 +0200, Heikki Linnakangas wrote:
>
>> initdb on one platform, copy the data directory over to the other
>> system, and try to start postmaster. It will complain if the on-disk
>> format is not compatible.
>>
>> You can also run pg_controlinfo on
nor version?)
- same CPU architecture
I was hoping it was a simple set of requirements, but that's life.
--
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/
Tom Lane wrote:
> I think pretty much everybody except Philip Warner has found the stuff
> around the TOC data structure and the "archiver" API to be confusing.
> I'm not immediately sure about a better design though, at least not if
> you don't want to duplicate
Tom Lane wrote:
> It would be fairly easy, I think, to add some reloption fields that
> would let these parameters be controlled on a per-table level.
> Per-column would be much more painful; do we really need that?
>
Another +1 on the per-table setting. Or a config file setting to disable
this
Alex Hunsaker wrote:
> For the record I just imported a production database that sits at
> about ~20G right now with *zero* size increase (rounding to the
> nearest gigabyte). That's with basically the exact same schema just
> different data.
>
>
Guessing you don't have many plain text rows >
shakahsha...@gmail.com wrote:
> -- PostgreSQL database dump
> --
> -- pg_dump version: 8.5devel
> --
> -- remote database version: 8.5devel (80500)
> --
>
FWIW, and I havent read the entire thread, but pg_dump already *stores*
this information in a custom format. Try:
pg_dump -Fc blah
pg_rest
At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>And how about getting database internals via SQL-functions - e.g. getting
>BLCSIZE, LOBBLCSIZE?
ISTM that there would be some merit in making a selection of compile-time
options available via SQL. Is this worth considering?
---
At 11:50 25/04/02 -0400, Bruce Momjian wrote:
>Marc G. Fournier wrote:
> >
> > Just curious here, but has anyone taken the time to see how others are
> > doing this? For instance, if we go with 1, are going against how everyone
> > else handles it? IMHO, its not a popularity contest ...
Dec/RDB
d an attr
deleted.
In your responses you also raised the problem of COPY having to know about
default values for columns if we allow subsets of columns when we load
data; does that mean that COPY does something more fancy than the
equivalent of an INSERT?
--------
is none), or a view, eg. pg_temporary_tables?
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82
ality going into a future version?
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
At 00:18 17/08/2002 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
> > Obviously this is not a 7.3 item, but would people support such
> > functionality going into a future version?
>
>Actually, I wouldn't.
This forces application-based caches,
the function manager?
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 |
ction, as well as any external function that is expensive to execute.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 8
lt is cached and next time the function is called with
>the same argument(s) the result is retrieved from the cache instead of the
>function being run again.
Exactly. But obviously not limited to simple mathematical functions.
--------
ion.
----
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82
1.lis
to remove the line for the language definition, and run pg_restore -L
dump1.lis.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N
views can also be on other
views. I presume the bad ordering happened as a result of a drop/create on
a table? Or is there some other cause?
----
Philip Warner| __---_
Albatross Consulting Pt
w about
dependencies, so we can't use the rudimentary support for dependencies in
pg_dump.
>---(end of broadcast)---
>TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
types)?
----
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___
can check the return
type, and create it with the correct return type (with warning). We just
need to make sure that the language handlers are listed as returning the
correct type.
--------
Philip Warner| __---
cked. And in the case of the plpgsql handlers,
they would of course be defined.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@)
At 01:42 PM 13/09/2002 +1000, Philip Warner wrote:
>Not all functions would need to use these, but when a user defines a
>function they could be checked. And in the case of the plpgsql handlers,
>they would of course be defined.
ISTM that this problem comes about because we allow an
to
anybody else?
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81
ch data is in the stream.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 |
At 09:42 AM 2/10/2002 +1000, Philip Warner wrote:
>Yes, and do the peripheral stuff to support old archives etc.
Does silence mean people agree? Does it also mean someone is doing this
(eg. whoever did the off_t support)? Or does it mean somebody else needs to
do
ely ignores endian-ness at the 32 bit scale?
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 05
nt/int file
offsets, I don't see we have mush choice.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61)
he large file API have functions for representing
the off_t values that is portable across architectures? And is the API also
portable?
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ -
Fine with me, unless anybody voices another opinion in the next day, I will
proceed. I just have this vague recollection of seeing a header file with a
more complex structure for off_t. I'm probably dreaming.
-------
At 12:49 AM 14/10/2002 -0400, Bruce Momjian wrote:
> Fix pg_dump to handle 64-bit off_t offsets for custom format
I'll try to get back to this in the next day or so...
----
Phili
ially).
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___ |
If you are concerned about reading a dump file with 8 byte offsets on a
machine with 4 byte off_t, that case and it's permutations are already covered.
----
Philip Warner| __---_
Albatross Consulting
ten it does not matter if this is a 16 or
3 byte value - so long as it is an integer.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) |
7;hasSeek' - don't screw around with every seek call. But only modify clear
it if the file is > 4GB.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/
At 09:41 PM 23/10/2002 -0400, Bruce Momjian wrote:
If we get this, everything is fine. I have done that for BSD/OS today.
I may need to do the same for NetBSD/OpenBSD too.
What did you do to achieve this?
Philip Warner
- I am ver happy to change that to SEEK_SET - I can't even recall why I
used SEEK_CUR. The code that does the real seeks uses SEEK_SET.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/
At 11:55 AM 24/10/2002 +1000, Philip Warner wrote:
The only code that uses SEEK_CUR is the code to check if seek is available
- I am ver happy to change that to SEEK_SET - I can't even recall why I
used SEEK_CUR. The code that does the real seeks uses SEEK_SET.
Come to think of it:
ctx->hasSeek = fseeko(...,SEEK_SET);
#else
ctx->hasSeek = FALSE;
#endif
pipes are the main case for which we are checking.
--------
Philip Warner| __---_
Albatross Consulti
we would then just
revert to calling fseek/ftell etc.
----
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0
At 12:32 AM 23/10/2002 -0400, Tom Lane wrote:
I am wondering why pg_dump has to depend on either fseek or ftell.
It doesn't - it just works better and has more features if they are
available, much like zlib etc.
Philip W
At 12:29 AM 23/10/2002 -0400, Bruce Momjian wrote:
This fseeko/ftello/off_t is just too fluid, and the
failure modes too serious.
I agree. Can you think of a better solution than the one I suggested???
Philip Warner
rs (which as you know I
don't like), we should have no problems.
If a system does not have any function to access 64 bit file offsets, then
I'd say they are pretty unlikely to have files > 2GB.
--------
Philip Warner
will not be a problem.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83
works now.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83
ommit the changes.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+
s sizes of int and offset.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (
At 09:18 PM 20/10/2002 -0400, Bruce Momjian wrote:
I will try to apply it within the next 48 hours.
I'm happy to apply it when necessary; but I wouldn't do it until we've from
some someone with a big-endian machine...
----
n someone offer a bigendian machine
and/or a 4 byte off_t machine?
was integral.
----
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 00
.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax
s not supported for off_t (how likely is
that?). I agree shift is definitely the way to go if it works on arbitrary
data - ie. it does not rely on off_t being an integer. Can I shift a struct?
Philip W
The patch will not work. Please reread my quoted email.
At 09:32 PM 24/10/2002 -0400, Bruce Momjian wrote:
Philip Warner wrote:
>
> You are quite correct. It should read:
>
> #ifdef HAVE_FSEEKO
> ctx->hasSeek = fseeko(...,SEEK_SET);
> #els
^^^
> > > #else
> > > ctx->hasSeek = FALSE;
> > > #endif
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 65
is easy, even in a macro.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (
e that
it may break as discussed.
AFAICT, using storage order will not break under any circumstances within
one OS/architecture (unlike using shift), and will not break any more often
than using shift in cases where off_t is integral.
-----
I just reread the patch; is it valid to assume fseek and fseeko have the
same failure modes? Or does the call to 'fseek' actually call fseeko?
--------
Philip Warner| __---_
Albatross Consultin
oken OS
implementations of off_t.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 |
#define FILE_OFFSET long
#define FSEEK fseek
#end if
...assuming you have a non-broken 64 bit fseek/tell pair, then this will
work in all cases, and make the code a lot less ugly (assuming of course
the non-broken version can be shifted).
-----
than just this.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___
e introduced
if a table has more than a 'RandomPageCost/SequentialPageCost' ratio of
dead:live tuples. Or we should always add a PK scan into the list of
strategies considered.
--------
Philip Warner
At 07:39 PM 2/11/2002 +1100, Philip Warner wrote:
To give some numbers:
And some more numbers, directly after a vacuum and analyze:
mail=# explain analyze select * from often_updated where id between
'-1' and '10';
Index Scan using barnet_users_id on often_updated
any stats about dead tuples.
What it knows about are live tuples and total disk pages occupied by
the table.
So what made it choose the index scan? Does it make guesses about tuple
sizes, and predict empty space?
------
res as you
suggest.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 050
lting to dependency-order).
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _
of
the dependencies.
The latter will be substantially improved if we can get pg_depend deps into
the dump file, and if we can do a useful analysis of the dependencies.
Philip Warner| __---_
Albatross
analysis of
the dependencies meant we needed to break up an object, then we use the
latter.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498)
tentious item might be table attrs? is that right?
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@)
everything else that depends on it will fail. This has the
advantage of being simple.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 0
rth considering.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _
...
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 03 5330 3172 | ___ |
Http
ctive of the 'DEFAULT' clause.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61
uch slower).
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 03
add support in pg_dump.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61)
At 05:33 PM 29/11/2002 -0800, Christopher Kings-Lynne wrote:
Hmmm. I could have sworn that someone (Neil?) already did that?
Not AFAICT - at least based on looking at the manual. I'll check the code.
Philip W
ttempting a reindex results in:
# reindex table tt;
WARNING: table "tt" wasn't reindexed
REINDEX
Any help and/or pointers would be appreciated.
--------
Philip Warner| __---_
Albat
uch busier days, and I'll
se what happens.
Is there any way (other than VACUUM FULL) to recover the current lost space?
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.
user base inconvenienced in an
effort to purely gain that market share. I usually associate increased
marketing with decreased quality, and I think the causality works *both* ways.
--------
Phi
a number of issues that caused existing users &
developers problems. It was probably also an interesting project. Maybe I'm
wrong...
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |-
o at least 12288 for this table, despite the
fact that only 8192 pages were released (since we assume there may be bulk
deletes freeing up many pages).
If VACUUM were run twice as often, the max_fsm_pages should be set to at
least 6144 for this table.
-
st never* subject to deletes or updates. They are certainly
common in DB design, but I'd let the DBA designate them.
Does this sound reasonable?
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd.
n
runtime configuration.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 050
relkind in ('r', 't', 'i');
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81
36 2002-12-10 12:08 16979
oddly (bug? edge behaviour?) doing two vacuums in a row results in the free
space being used.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd.
At 12:17 PM 10/12/2002 +1100, Philip Warner wrote:
Secondly, an empty database contains 98 tables,
Corrected based on Tom's later mail; from the FSM PoV, it contains 37
(indices don't count). So it is exhausted when more than two DBs a
uses free space
my guess is the fact that the second vacuum has no useful statistics means
that (somehow) it is choosing the tables with free space -- perhaps because
they are the largest?
----
Phil
_history' table.
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax
At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:
but I'm sure Glenn would be pleased to send 'em to
you on request.
Do you have an email address - the O'Reilly site also seems not to have one...
-------
At 01:56 AM 10/12/2002 -0500, Tom Lane wrote:
but I'm sure Glenn would be pleased to send 'em to
you on request.
I've found a link:
http://www.delphis.com/java/java.html
-------
\b, \j, \k ,
\m, \n, \u, \v, and \y are available. I'd vote for \v (view), or \k
(command). The go with:
\v schema
or
\k show schema
(I'd vote for \v).
--------
Philip Warner| __---_
tion attrs).
--------
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 03
1 - 100 of 540 matches
Mail list logo
