On 02/10/14 18:13, Tom Lane wrote:
Cedric Berger writes:
1) What is the easiest way to get that directly in C?
The usual locution is "get_database_name(MyDatabaseId)".
Ok, but then how do I find "MyDatabaseId" in, say,
a BeginForeignScan() or GetForeignRelSize() FDW callback?
http://www.
On 03/10/2014 05:54, Jim Nasby wrote:
On 10/2/14, 9:00 AM, Tom Lane wrote:
Achilleas Mantzios writes:
Was there ever any discussion.thought about being able to follow a non-strict
by name
column mapping between inherited tables and father tables?
No. You could use a view with UNION ALL perh
Cedric Berger wrote:
>>> 1) What is the easiest way to get that directly in C?
>>
>> The usual locution is "get_database_name(MyDatabaseId)".
>
> Ok, but then how do I find "MyDatabaseId" in, say,
> a BeginForeignScan() or GetForeignRelSize() FDW callback?
It is a global, all you should have to d
On Fri, Oct 3, 2014 at 4:57 PM, Albe Laurenz
wrote:
> Cedric Berger wrote:
1) What is the easiest way to get that directly in C?
>>>
>>> The usual locution is "get_database_name(MyDatabaseId)".
>>
>> Ok, but then how do I find "MyDatabaseId" in, say,
>> a BeginForeignScan() or GetForeignRelSi
Hi,
retested:
yes, this is still an issue in 9.3.5, same deadlock errors occured.
Do you need to extract some simplified reproducible testcase?
Best Regards, Andrej
On 03/10/14 10:23, Michael Paquier wrote:
On Fri, Oct 3, 2014 at 4:57 PM, Albe Laurenz mailto:laurenz.a...@wien.gv.at>> wrote:
> Cedric Berger wrote:
1) What is the easiest way to get that directly in C?
>>>
>>> The usual locution is "get_database_name(MyDatabaseId)".
>>
>> Ok, but th
On Fri, Oct 3, 2014 at 1:28 AM, Andrus wrote:
> Hi!
>
>> So kellaaeg is a time? Your best bet here would be to create an index that
>> is an actual timestamp comprised of both >kuupaev and kellaaeg. You could do
>> this with to_timestamp by concatinating both fields together, or it may be
>> easie
The GUI installer for Mac OS X downloaded from postgresql.org works fine.
~ john
On Oct 2, 2014, at 3:50 PM, john.tiger wrote:
> we've always installed on linux so need help with a new mac air running
> latest osx
>
> in the instructions it shows several methods:
> 1) enterprisedb (b
Even if I try to delete the data entry in the table channel_mapping with
idaut 1622, it is not possible to delete from the table
tmp_autenticazionesocial with the error below. How is this even possible
since there is no channel_mapping with idaut 1622 any more?? I tried
this in Java under a transac
I've been able to fix most of my slow queries into something more acceptable,
but I haven't been able to shave any time off this one. I'm hoping someone has
another strategy.
I have 2 tables:
resource
resource_2_tag
I want to calculate the top 25 "tag_ids" in "resource_2_tag "
Using my magick powers of mind reading, I will guess you made circular
dependencies.
On Fri, Oct 3, 2014 at 12:17 PM, Tim Mickelson
wrote:
> Even if I try to delete the data entry in the table channel_mapping with
> idaut 1622, it is not possible to delete from the table
> tmp_autenticazionesocia
Hi!
Thank you for explanations.
the char type pads out the fields on disk.
It looks like you wrote that char takes more disk space.
from
http://www.pgcon.org/2013/schedule/attachments/269_tour-of-postgresql-data-types.pdf
page 28:
Unlikemany
databases,char(n)isNOTstor
On Fri, Oct 3, 2014 at 3:28 PM, Andrus wrote:
> Hi!
>
> Thank you for explanations.
>
>> the char type pads out the fields on disk.
>
>
> It looks like you wrote that char takes more disk space.
>
> from
>
> http://www.pgcon.org/2013/schedule/attachments/269_tour-of-postgresql-data-types.pdf
>
>
I have a Postgresql 9.3.5 server running on CentOS 6.5. In looking at some stats today, I saw that it was handling about 4-5 transactions/second (according to the SELECT sum(xact_commit+xact_rollback) FROM pg_stat_database; query), and an instance of the postmaster process was consistently showing
On Friday, October 03, 2014 11:24:31 AM Israel Brewster wrote:
> I have a Postgresql 9.3.5 server running on CentOS 6.5. In looking at some
> stats today, I saw that it was handling about 4-5 transactions/second
> (according to the SELECT sum(xact_commit+xact_rollback) FROM
> pg_stat_database; quer
On 10/03/2014 01:28 PM, Andrus wrote:
Hi!
Thank you for explanations.
the char type pads out the fields on disk.
It looks like you wrote that char takes more disk space.
from
http://www.pgcon.org/2013/schedule/attachments/269_tour-of-postgresql-data-types.pdf
page 28:
Unlikemany
da
Adrian Klaver writes:
>> page 28:
>>
>> Unlikemany
>> databases,char(n)isNOTstoredasafixed-sizedfield
>> inPostgres.Itistreatedexactlythesameas
>> varchar(n)exceptforbeingpadded
> Which directly contradicts the information on pag
On 10/03/2014 03:59 PM, Tom Lane wrote:
Adrian Klaver writes:
page 28:
Unlikemany
databases,char(n)isNOTstoredasafixed-sizedfield
inPostgres.Itistreatedexactlythesameas
varchar(n)exceptforbeingpadded
Which directly contradi
On 10/03/2014 04:40 PM, Alan Hodgson wrote:
On Friday, October 03, 2014 11:24:31 AM Israel Brewster wrote:
I have a Postgresql 9.3.5 server running on CentOS 6.5. In looking at some
stats today, I saw that it was handling about 4-5 transactions/second
(according to the SELECT sum(xact_commit+xac
But I don't think so, but here are the table defenitions:
CREATE TABLE bulldog.channel_mapping
(
idchannel integer NOT NULL,
idaut integer NOT NULL,
CONSTRAINT channel_mapping_pk PRIMARY KEY (idchannel, idaut),
CONSTRAINT channel_mapping_idaut_fkey FOREIGN KEY (idaut)
REFERENCES cub
20 matches
Mail list logo
