Suppose that you have a query, say $sql_query, which is very
complicated and produces many rows. Which of the following is going to
be faser:
$sql_query OFFSET 3000 LIMIT 12;
or
BEGIN;
DECLARE cur1 CURSOR FOR $sql_query;
MOVE 3000 IN cur1;
FETCH 12 FROM cur1;
COMMIT;
Nat
2009/10/26 Grzegorz Jaśkiewicz :
>
>
> On Mon, Oct 26, 2009 at 10:30 AM, silly wrote:
>>
>> Suppose that you have a query, say $sql_query, which is very
>> complicated and produces many rows. Which of the following is going to
>> be faser:
>>
>>
On Mon, Oct 26, 2009 at 10:28 AM, Alvaro Herrera
wrote:
> silly8888 escribió:
>> 2009/10/26 Grzegorz Jaśkiewicz :
>> >
>> >
>> > On Mon, Oct 26, 2009 at 10:30 AM, silly wrote:
>> >>
>> >> Suppose that you have a query, say $sql_q
In 8.4, the sequence value is copied only when INCLUDING DEFAULTS is
specified. Otherwise, only the not null constraint is copied. I think
this is the most reasonable behavior and I don't see why it should
have been explicitly stated in the manual.
On Fri, Oct 30, 2009 at 8:44 AM, Mark Morgan Llo
I have the following definitions:
--
create type mytype as (x integer, y integer);
create table foo(
a mytype primary key,
b integer
);
create table bar(
a mytype references foo
);
insert into foo values((0,0)::mytype,0);
---
How about using replication instead of incremental backups?
On Tue, Nov 10, 2009 at 4:56 PM, Alan Hodgson wrote:
> On Tuesday 10 November 2009, akp geek wrote:
>> So Is it always good to have the backup using PG_dump instead of PITR or
>> a combination of both
>>
>
> I like to do both. Ongoing P
You could try to prepare a query like this:
select name from foo where id=any($1);
and then pass the array of integers as $1 (although, I don't know how
you can do that as I've never used the C interface of libpq).
On Fri, Nov 13, 2009 at 1:34 AM, Matt Sanchez wrote:
> Hello,
>
> Suppose
SELECT * FROM (SELECT *,row_number() OVER (ORDER BY letztespeicherung
DESC) FROM rfmitzeit) t WHERE row_number=1
On Fri, Nov 20, 2009 at 5:31 AM, Massa, Harald Armin wrote:
> id_bf, wert, letztespeicherung:
>>>
>>> 98, 'blue', 2009-11-09
>>> 98, 'red', 2009-11-10
>>> now I have a
id_rf,
letztespeicherung DESC;
My guess is that the latter will perform better but you should do your
own testing.
On Fri, Nov 20, 2009 at 5:36 AM, silly wrote:
> SELECT * FROM (SELECT *,row_number() OVER (ORDER BY letztespeicherung
> DESC) FROM rfmitzeit) t WHERE row_number=1
>
>
> and how would I use DISTINCT ON for this query? Please bear in mind,
> that there is more then one id_bf (just stopped the sample data with
> one of them)
I posted the answer more than hour ago:
SELECT DISTINCT ON (id_rf) * FROM rfmitzeit ORDER BY id_rf,
letztespeicherung DESC;
The equivalent
> MySQL had the following syntax available:
> `updated_date` timestamp NOT NULL default CURRENT_TIMESTAMP on update
> CURRENT_TIMESTAMP
I wonder supporting this syntax would speed things up a little bit.
Here's a simple benchmark about the situation we are discussing here:
There are 2 tables:
How about:
IF date_trunc('month',NEW.effective_date)=date_trunc('month',now()) THEN
.
On Tue, Nov 24, 2009 at 7:22 AM, Michal Szymanski wrote:
> In our DB we create partition table for each month (our naming
> convetion is follow , and I would like to create trigger that insert
> d
Speaking of timestamps, I think it would be convenient to have a
single-word alias for "timestamp with time zone". This is the date
type I use almost exclusively and its name is annoyingly big.
On Sat, Nov 28, 2009 at 6:57 PM, Tom Lane wrote:
> Eduardo Piombino writes:
>> I see current criteri
>From
>http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES
Another issue to keep in mind is that in POSIX time zone names,
positive offsets are used for locations west of Greenwich.
On Sun, Nov 29, 2009 at 2:08 AM, wrote:
> The target pgsql is compiled fr
You can also use LISTEN/NOTIFY.
On Tue, Dec 1, 2009 at 6:25 PM, Bret wrote:
>> -Original Message-
>> From: pgsql-general-ow...@postgresql.org
>> [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Steve Atkins
>> Sent: Tuesday, December 01, 2009 9:44 AM
>> To: pgsql-general General
pg_dump dumps data first and then the constraints (including FK) so
there shouldn't be any problems when you import the dump.
On Wed, Dec 2, 2009 at 2:16 AM, Helio Campos Mello de Andrade
wrote:
> Hi guys,
>
> - I'm having a problem when i want to make a backup of my system.
> - Postgres gene
16 matches
Mail list logo
