Tim Uckun wrote
> 1. Should I be worried about having possibly hundreds of thousands of
> shards.
IIRC, yes.
> 2. Is PG smart enough to handle overlapping constraints on table and limit
> it's querying to only those tables that have the correct time constraint.
Probably yes, but seems easy enou
I have two partitioning questions I am hoping somebody can help me with.
I have a fairly busy metric(ish) table. It gets a few million records per
day, the data is transactional for a while but then settles down and is
used for analytical purposes later.
When a metric is reported both the UTC tim
On 02/05/2015 03:41 PM, Tim Smith wrote:
So either PostgreSQL is seeing a different view (in a different schema) or the
function is confused in ways difficult to predict.
Seriously ? You still want to continue calling it user-error ? There
is no other view, there is no other schema , I am not
On 02/05/2015 03:25 PM, Tim Smith wrote:
PostgreSQL doesn't lie
Well if its not lying its one big stinking bug !
In my experience Postgres does not randomly make up error messages.
Somewhere it is seeing a duplicate column.
How about you tell me where you see these duplicate columns in m
Tim Smith writes:
> Yes, well PostgreSQL is being incredibly unhelpful in that respect, it
> says "(SQLSTATE: 42702 - SQLERRM: column reference "session_id" is
> ambiguous)" ... but that is an utter lie. There is only one column
> called session_id in my view (in both the view output and the
>
app_sessions is a table and app_users_vw is not hiding anything from you :
tenant_id
tenant_name
tenant_shortname
reseller_id
user_id
user_failedlogins
user_fname
user_lname
user_email
user_phone
user_passwd
user_seed
user_hidden
user_candelete
user_newseed
user_lastupdate
tenant_
> So either PostgreSQL is seeing a different view (in a different schema) or
> the function is confused in ways difficult to predict.
Seriously ? You still want to continue calling it user-error ? There
is no other view, there is no other schema , I am not hiding anything
from you !
On 5 Februa
On Thu, Feb 5, 2015 at 4:29 PM, Tim Smith
wrote:
> You're most welcome to look at my view definition view if you don't
> believe me
>
> View definition:
> SELECT a.session_id,
> a.session_ip,
> a.session_user_agent,
> a.session_start,
> a.session_lastactive,
> b.user_id,
You're most welcome to look at my view definition view if you don't
believe me
View definition:
SELECT a.session_id,
a.session_ip,
a.session_user_agent,
a.session_start,
a.session_lastactive,
b.user_id,
b.tenant_id,
b.reseller_id,
b.tenant_name,
b.user_fna
> PostgreSQL doesn't lie
Well if its not lying its one big stinking bug !
How about you tell me where you see these duplicate columns in my view
that PostgreSQL is apparently not lying to me about
View "public.app_val_session_vw"
Column | Type | Modifiers
--
On Thu, Feb 5, 2015 at 4:01 PM, Tim Smith
wrote:
> > returning more than one row? v_row can only hold one row at a time.
>
> Absolutley not. (a) My where clause is a primary key (b) I have
> checked it manually, it only returns one row
>
> >You really need to provide error messages
>
> Yes, wel
On 02/05/2015 03:01 PM, Tim Smith wrote:
> returning more than one row? v_row can only hold one row at a time.
Absolutley not. (a) My where clause is a primary key (b) I have
checked it manually, it only returns one row
Well since there was no error message provided and my psychic hat is in
> returning more than one row? v_row can only hold one row at a time.
Absolutley not. (a) My where clause is a primary key (b) I have
checked it manually, it only returns one row
>You really need to provide error messages
Yes, well PostgreSQL is being incredibly unhelpful in that respect, it
s
Tim Smith-2 wrote
> Hi,
>
> I have a function that broadly looks like this :
>
> create function doStuff() returns json as $$
> DECLARE
> v_row my_view%ROWTYPE;
> BEGIN
> select * into strict v_row from my_view where foo=bar;
> select row_to_json(v_row) from v_row;
> END;
> $$ LANGUAGE plpgsql;
>
On 02/05/2015 01:38 PM, Tim Smith wrote:
Hi,
I have a function that broadly looks like this :
create function doStuff() returns json as $$
DECLARE
v_row my_view%ROWTYPE;
BEGIN
select * into strict v_row from my_view where foo=bar;
select row_to_json(v_row) from v_row;
END;
$$ LANGUAGE plpgsql;
Hi,
I have a function that broadly looks like this :
create function doStuff() returns json as $$
DECLARE
v_row my_view%ROWTYPE;
BEGIN
select * into strict v_row from my_view where foo=bar;
select row_to_json(v_row) from v_row;
END;
$$ LANGUAGE plpgsql;
However this does not seem to work ? Wh
Hey,
I'm not a guru, here is what I understood.
You are mixing several problems in the same question :
- 1. why the planner isn't more efficient
- 2. why the workaround is difficult to use with an ORM.
for 1. you can't do much (as said by others, you don't really need a case
here anyway). I thin
2015-02-05 15:56 GMT+01:00 Tom Lane :
> Sterfield writes:
> > I'm a sysadmin working for an application that stores all its data in a
> PG
> > database.
> > Currently, the cluster has its encoding set to UTF-8, and the locale
> (both
> > LC_COLLATE and LC_CTYPE) is set to 'en_US.UTF-8'.
>
> > I d
Sterfield writes:
> I'm a sysadmin working for an application that stores all its data in a PG
> database.
> Currently, the cluster has its encoding set to UTF-8, and the locale (both
> LC_COLLATE and LC_CTYPE) is set to 'en_US.UTF-8'.
> I discovered recently that the indexes created on varchar f
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Guillaume Drolet
Sent: Thursday, February 05, 2015 8:29 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Error: could not read symbolic link "pg_tblspc/940585". No
such file or directory
Dea
Dear list users,
I moved a database from a tablespace I had created to pg_default using:
ALTER DATABASE mydatabase SET TABLESPACE pg_default;
After the database was fully copied to a new directory under PGDATA/base, I
deleted the symbolic link to the old tablespace using (in Windows) rmdir
PGDAT
Hi everyone,
I'm a sysadmin working for an application that stores all its data in a PG
database.
Currently, the cluster has its encoding set to UTF-8, and the locale (both
LC_COLLATE and LC_CTYPE) is set to 'en_US.UTF-8'.
I discovered recently that the indexes created on varchar fields are not
w
22 matches
Mail list logo
