hi,
i tried to test new "visibility map" feature.
to do so i:
1. fetched postgresql sources from cvs
2. compiled
3. turned autovacuum off
4. started pg
5. ran this queries:
- CREATE TABLE test_1 (i INT4);
- CREATE TABLE test_2 (i INT4);
- CREATE TABLE test_3 (i INT4);
- CREATE TABLE test_4
I was making some table creation on one of our development DB and found
that psql's \dt has problems showing all tables available. Basically, if
you have to tables with the same name in different schemas, only one
will be listed (the one on the schema that is first in the search_path).
IMHO, \
On Sat, Dec 6, 2008 at 8:50 AM, Martin Marques
<[EMAIL PROTECTED]>wrote:
> I was making some table creation on one of our development DB and found
> that psql's \dt has problems showing all tables available. Basically, if you
> have to tables with the same name in different schemas, only one will
Diego Schulz escribió:
Hi,
Schemas are a lot like directories at operating system level (except
that can't be nested).
When you ls (or dir) in /home/martin/ , normally you don't expect to
see /home/johnny/ listed as well.
But if you really want to see all tables, try adjusting search_pa
On Sat, Dec 6, 2008 at 10:00 AM, Martin Marques
<[EMAIL PROTECTED]>wrote:
> Diego Schulz escribió:
>
>>
>>
>> Hi,
>>
>>
>> Schemas are a lot like directories at operating system level (except that
>> can't be nested).
>> When you ls (or dir) in /home/martin/ , normally you don't expect to see
>>
On Sat, Dec 6, 2008 at 6:46 AM, hubert depesz lubaczewski
<[EMAIL PROTECTED]> wrote:
> hi,
> i tried to test new "visibility map" feature.
here's the test again in a more illustrative way:
postgres=# INSERT INTO test_1 SELECT generate_series(1, 1);
INSERT 0 1
Time: 136229.455 ms
po
Hi all,
Here's an odd one:
itidb=> \d joblist;
Table "public.joblist"
Column | Type | Modifiers
---+--+---
full_name | character varying(64)| not null
email_address | charact
On Sat, Dec 6, 2008 at 10:27 AM, Sebastian Tennant
<[EMAIL PROTECTED]> wrote:
> itidb=> update joblist set (full_name, email_address, recruiter,
> itidb(> subscribed, verified, created_at, updated_at) =
> itidb-> ('[name hidden]', '[email address hidden]', false, true
> itidb(> true, current_ti
On Sat, Dec 6, 2008 at 8:38 AM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> So what do we gather from this? Well, the feature works as
> advertised. I think that as long as your updates are not uniformly
> distributed across pages, vismap is a huge performance win for many
> workloads. I think t
Hi Osvaldo,
Your list_fields function looked interesting to me so I tried it out and
it only worked for one of the five or so tables in the database I was
connected to at the time.
More concerning is the fact that I can't seem to drop it. I'm told it
doesn't exist, and then I use it to prove (to
Quoth "Merlin Moncure" <[EMAIL PROTECTED]>:
> It looks to me like you are setting the whole table to the same
> address in the update statement (no where clause)...so of course you'd
> get the error. Maybe you want to do an insert statement?
>
> merlin
Doh! Thanks Merlin. I'm so glad it's just
On 06/12/2008 16:02, Sebastian Tennant wrote:
> Here's it working:
>
> itidb=> select list_fields('joblist');
> Here's me trying to drop it, only to be told it doesn't exist:
>
> itidb=> drop function list_fields();
> ERROR: function list_fields() does not exist
You need to specify the ar
Quoth Raymond O'Donnell <[EMAIL PROTECTED]>:
> On 06/12/2008 16:02, Sebastian Tennant wrote:
>> Here's it working:
>>
>> itidb=> select list_fields('joblist');
>
>
>
>> Here's me trying to drop it, only to be told it doesn't exist:
>>
>> itidb=> drop function list_fields();
>> ERROR: functio
Diego Schulz wrote:
> > Sorry, forgot to say that I SET search_path acordinlly to see relations
> > from both schemas. But whan the table has the same name I only get the one
> > from the first schema in the search_path.
> >
>
>
> I can confirm the behaviour you described.
Yes, \dt was designed
Anyone?
--- On Fri, 5/12/08, Glyn Astill <[EMAIL PROTECTED]> wrote:
> From: Glyn Astill <[EMAIL PROTECTED]>
> Subject: [GENERAL] Planner picking topsey turvey plan?
> To: pgsql-general@postgresql.org
> Date: Friday, 5 December, 2008, 2:23 PM
> Hi people,
>
> Does anyone know how I can change wh
what does explain analyze yourqueryhere say?
On Sat, Dec 6, 2008 at 1:33 PM, Glyn Astill <[EMAIL PROTECTED]> wrote:
> Anyone?
>
>
> --- On Fri, 5/12/08, Glyn Astill <[EMAIL PROTECTED]> wrote:
>
>> From: Glyn Astill <[EMAIL PROTECTED]>
>> Subject: [GENERAL] Planner picking topsey turvey plan?
>> To
Explain analyze below,
DB=# explain analyze select a.artist, a.date, b.mult_ref, b.items, b.parts from
(show a inner join orders b on a.code = b.show) where artist = 'ALKALINE TRIO';
QUERY PLAN
---
17 matches
Mail list logo
