Glen Parker wrote:
> As was already mentioned, application logs. Unlogged tables would be
> perfect for that, provided they don't go *poof* every now and then for
> no good reason. Nobody's going to be too heart broken if a handful of
> log records go missing, or get garbled, after a server crash
Hi,
a question that I imagine is a faq but have not been able to find much help.
How do people implement insert or upate ( otherwise known as upsert ) behaviour
in postgres i.e. insert a row if it's key does not exist in the database else
update the existing row?
I tried using an insert rule t
On Friday 19 November 2010 2:45:33 pm Tom Lane wrote:
> Adrian Klaver writes:
> > Now I understand. I wonder if this would be a good time to ask about
> > whether pg_restore could be made to work with plain-text files:)
>
> Not in any particularly useful way --- the plain text dump wouldn't
> real
On 11/19/10 23:14, Andy Colson wrote:
On 11/19/2010 4:04 PM, Ivan Voras wrote:
On 11/19/10 15:49, Andy Colson wrote:
unlogged will only help insert/update performance. Lookup tables sound
readonly for a majority of time. (I'm assuming lots of reads and every
once and a while updates). I doubt
"Joshua D. Drake" writes:
> On Fri, 2010-11-19 at 17:45 -0500, Tom Lane wrote:
>> Not in any particularly useful way --- the plain text dump wouldn't
>> really support selective restore, etc etc.
> It would however lend to consistency in our user interface. It is really
> quite silly that pg_rest
On Fri, 2010-11-19 at 17:45 -0500, Tom Lane wrote:
> Adrian Klaver writes:
> > Now I understand. I wonder if this would be a good time to ask about
> > whether pg_restore could be made to work with plain-text files:)
>
> Not in any particularly useful way --- the plain text dump wouldn't
> reall
Adrian Klaver writes:
> Now I understand. I wonder if this would be a good time to ask about
> whether pg_restore could be made to work with plain-text files:)
Not in any particularly useful way --- the plain text dump wouldn't
really support selective restore, etc etc.
> ... Though I could see
On 11/19/2010 4:04 PM, Ivan Voras wrote:
On 11/19/10 15:49, Andy Colson wrote:
unlogged will only help insert/update performance. Lookup tables sound
readonly for a majority of time. (I'm assuming lots of reads and every
once and a while updates). I doubt that unlogged tables would speed up
loo
On 11/19/10 15:49, Andy Colson wrote:
unlogged will only help insert/update performance. Lookup tables sound
readonly for a majority of time. (I'm assuming lots of reads and every
once and a while updates). I doubt that unlogged tables would speed up
lookup tables.
Are FreeBSD's temp tables st
I considered this, however the subquery is generated by an ORM. I
wanted to separate it.
Also the whole join affects many rows. I thought it's cheaper to
preselect them inside the subquery then do the join. I am not sure.
Explain analyze is my good friend but in this case I prefer to ask.
#
On 11/19/2010 03:21 AM, Thom Brown wrote:
You should always use ORDER BY on the outer-most part of the query
since that's what will be finally returning your data. Don't bother
with ordering sub-selects.
I definiatelly have to use the "order by" inside for two reasons.
When "distinct on (x)"
On Fri, Nov 19, 2010 at 1:41 PM, Scott Ribe wrote:
> And I tried to make the "it only involves a single t1 and matches a single
> partition" more explicit, but this didn't do it either:
>
> explain with tbl as (select id from t1 where name = 'foo')
> select * from t1, t2 where t1.id = t2.t1_id an
On Fri, Nov 19, 2010 at 1:09 PM, Tom Lane wrote:
> Jon Nelson writes:
>> On Fri, Nov 19, 2010 at 12:14 PM, Tom Lane wrote:
>>> Hard to comment about this with such an incomplete view of the situation
>>> --- in particular, data types would be a critical factor, and I also
>>> wonder if you're ad
Jon Nelson writes:
> On Fri, Nov 19, 2010 at 12:14 PM, Tom Lane wrote:
>> Hard to comment about this with such an incomplete view of the situation
>> --- in particular, data types would be a critical factor, and I also
>> wonder if you're admitting to all the columns involved.
> Here is an examp
On 11/19/2010 09:54 AM, Tom Lane wrote:
Adrian Klaver writes:
On Friday 19 November 2010 8:29:38 am Tom Lane wrote:
It sounds like you're trying to use pg_restore on a plain-text (SQL
script) dump file. Run it through psql, instead.
Out of curiosity what would trigger this? When I have tri
On 11/19/10 3:52 AM, Vangelis Katsikaros wrote:
Hello
I use postgres 8.3.12 on machineA and 8.4.5 on machineB.
On machineA I have created a tablespace with
CREATE TABLESPACE tablelocation_name LOCATION '/my/location/machineA';
I then created a database with
CREATE DATABASE db_name TABLESPACE t
Consider the following test setup:
create table t1 (
id int8 primary key,
name varchar not null unique
);
create table t2 (
id int8 primary key,
t1_id int8 not null references t1
);
create table t2a (
primary key(id),
check(t1_id = 1)
) inherits (t2);
create table t2b (
primary key(id),
check(t
On Fri, Nov 19, 2010 at 12:14 PM, Tom Lane wrote:
> Jon Nelson writes:
>> What influences the calculation of the 'width' value in query plans?
>
> It's generally the sum of the estimated column widths for all the
> columns needed at that particular level of the plan.
>
>> Specifically, I have two
Jon Nelson writes:
> What influences the calculation of the 'width' value in query plans?
It's generally the sum of the estimated column widths for all the
columns needed at that particular level of the plan.
> Specifically, I have two queries which both query the same set of
> tables via either
Adrian Klaver writes:
> On Friday 19 November 2010 8:29:38 am Tom Lane wrote:
>> It sounds like you're trying to use pg_restore on a plain-text (SQL
>> script) dump file. Run it through psql, instead.
> Out of curiosity what would trigger this? When I have tried to run a
> plain text file throug
What influences the calculation of the 'width' value in query plans?
Specifically, I have two queries which both query the same set of
tables via either UNION or UNION ALL based on the presence (or
absence) of an aggregate function.
Like this:
SELECT a, b FROM foo_1 WHERE a = 'bar'
UNION
SELECT a
On Friday 19 November 2010 8:29:38 am Tom Lane wrote:
> Andreas Laggner writes:
> > i cannot restore my data from 8.2 to 8.4 because i always get this error
> > message, does anyone know what to do??
>
> It sounds like you're trying to use pg_restore on a plain-text (SQL
> script) dump file. Run
Andreas Laggner writes:
> i cannot restore my data from 8.2 to 8.4 because i always get this error
> message, does anyone know what to do??
It sounds like you're trying to use pg_restore on a plain-text (SQL
script) dump file. Run it through psql, instead.
regards, tom
On Friday 19 November 2010 8:02:55 am Andreas Laggner wrote:
> Hi list,
>
> i cannot restore my data from 8.2 to 8.4 because i always get this error
> message, does anyone know what to do??
>
> hasta luegoAndreas
>
>
>
Two questions:
Are you using the 8.2 or 8.4 version of pg_dump/pg_res
Hi list,
i cannot restore my data from 8.2 to 8.4 because i always get this error
message, does anyone know what to do??
hasta luegoAndreas
--
Dipl. Geoökologe Andreas Laggner
Institut für Agrarrelevante Klimaforschung (AK) des vTI
Arbeitsgruppe Emissionsinventare
Johann Heinrich v
On 11/18/2010 4:56 PM, Fredric Fredricson wrote:
Hi,
I have designed a handful databases but is absolutely no SQL-expert. Nor
have I had any formal database training and have never worked with
someone who had. What I know about SQL I have read in the documentation,
found with google, and learned
Dne 19.11.2010 05:56, Tom Lane napsal(a):
> Tomas Vondra writes:
>> We need to identify whether the stats were reset between the snapshots,
>> because then the collected data are useless (and the scripts that do the
>> analysis are quite confused).
>
> The stats are never reset automatically.
Th
The problem is that there is a lot of metadata outside the tablespace you
created (information that the catalog tables keep on your new database and
its objects) and this can only be restored with a full restore which would
overwrite your pre-existing databases on your target. I hate to say it
can
On 11/19/2010 03:12 PM, Matthew Walden wrote:
Vangelis,
I don't believe you can do file level copying of single databases
(especially as they are different versions).
Hi Matthew, thanks for your answer.
If the different versions is a problem, I can downgrade one server and
then upgrade after
Vangelis,
I don't believe you can do file level copying of single databases
(especially as they are different versions).
Take a look at pg_dump in the documentation. This will do what you need I
think but at a logical level rather than physical.
On Fri, Nov 19, 2010 at 11:52 AM, Vangelis Katsik
Hello
I use postgres 8.3.12 on machineA and 8.4.5 on machineB.
On machineA I have created a tablespace with
CREATE TABLESPACE tablelocation_name LOCATION '/my/location/machineA';
I then created a database with
CREATE DATABASE db_name TABLESPACE tablelocation;
I created tables, inserted data an
Hello,
> > Thank you for the reply. But my doubt was not about layout, rather the
> > DMLs. If I do an insert into an 'unlogged' table, what happens to
that?
> > Will that be replicated in the slave (using PostgreSQL's inbuilt
> > replication)?
>
> What are the use-cases for replicating unlo
32 matches
Mail list logo
